is changed to 
, where N is the number of sub-slots in an UL slot.Please refer to RP-201310 for detailed scope of the WI
R1-2006338 Work Plan for Rel-17 NR IIoT/URLLC Enhancements WI Nokia, Nokia Shanghai Bell
R1-2005243 UE feedback enhancements for HARQ-ACK Huawei, HiSilicon
· Proposal 1：Sub-slot based type 1 HARQ-ACK codebook construction should be supported in Rel-17.
· Proposal 2：PUCCH repetitions over sub-slots should be supported in Rel-17.
· Proposal 3：ACK skipping and/or NACK skipping should be supported for DL SPS in Rel-17.
· Proposal 4：In case of collision with invalid symbol(s) for UL transmission, HARQ-ACK postponing for DL SPS should be considered in Rel-17.
· Proposal 5：Dynamic PUCCH carrier switching could be considered for TDD carriers in Rel-17.
· Proposal 6：The following two options could be considered for power control enhancements for PUCCH in Rel-17:
o Option 1: Enlarging the range of TPC command for PUCCH
o Option 2: Dynamically indicating open-loop power control of PUCCH in DCI.
· Proposal 7: Regardless of the configured maximum number of code words, HARQ-ACK codebook construction based on only one code word could be considered for HARQ-ACK codebook with high priority in Rel-17.
Decision: The document is noted.
R1-2005633 On UE feedback enhancements for HARQ-ACK MediaTek Inc.
· Proposal 1: Introduce dynamic cross-carrier PUCCH for Carrier Aggregation.
· Proposal 2: Support non-transparent CDD for PUCCH transmission.
· Proposal 3: Support DMRS overlap with N1 leading to latency enhancement.
Decision: The document is noted.
R1-2005374 HARQ-ACK enahncements for Rel-17 URLLC vivo
R1-2005431 Discussion on HARQ-ACK enhancements for eURLLC ZTE
R1-2005513 HARQ-ACK Enhancements for IIoT/URLLC Ericsson
R1-2005569 HARQ-ACK enhancement to reduce retransmission time Sony
R1-2005701 UE feedback enhancements for HARQ-ACK CATT
R1-2005760 Enhancements on URLLC HARQ-ACK feedback NEC
R1-2005869 UE HARQ feedback enhancements in Release 17 URLLC/IIoT Intel Corporation
R1-2005929 HARQ-ACK feedback enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2005967 UE feedback enhancements for HARQ-ACK TCL Communication Ltd.
R1-2006058 HARQ-ACK enhancements for Rel-17 URLLC/IIoT OPPO
R1-2006070 UE HARQ-ACK feedback enhancements InterDigital, Inc.
R1-2006139 HARQ-ACK feedback enhancements for Rel-17 URLLC/IIoT Samsung
R1-2006207 Discussion on UE feedback enhancements for HARQ-ACK CMCC
R1-2006252 Discussion on necessity and support of physical layer feedback enhancements Spreadtrum Communications
R1-2006314 Discussion on UE feedback enhancement for HARQ-ACK LG Electronics
R1-2006339 On the necessity and support of Rel-17 URLLC HARQ-ACK feedback enhancements Nokia, Nokia Shanghai Bell
R1-2006342 Discussion on UE feedback enhancements for HARQ-ACK Panasonic Corporation
R1-2006514 UE feedback enhancements for HARQ-ACK Apple
R1-2006572 UE feedback enhancements for HARQ-ACK Sharp
R1-2006639 Discussion on HARQ-ACK enhancements Asia Pacific Telecom co. Ltd
R1-2006728 Discussion on HARQ-ACK feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
R1-2006799 HARQ-ACK enhancement for IOT and URLLC Qualcomm Incorporated
R1-2006887 Discussion on HARQ-ACK enhancement for IIoT/URLLC WILUS Inc.
R1-2006899 HARQ enhancement for SPS Google, Inc.
[102-e-NR-IIOT_URLLC_enh-01] – Nokia (Klaus)
Email discussions/approval
· By 8/21 – high priority
· By 8/27 – medium
R1-2007059 Feature lead summary #1 on Rel-17 HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
R1-2007107 Feature lead summary #2 on Rel-17 HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
Agreements:
Support Rel-17 enhancements to avoid SPS HARQ-ACK dropping for TDD due to PUCCH collision with at least one DL or flexible symbol.
· This topic is to be considered as high priority
· FFS detailed solution(s)
R1-2007216 Feature lead summary #3 on Rel-17 HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
Agreements:
· Simultaneous PUSCH / PUCCH within a cell group (of Sec. 6.13 of R1-2007216) and enhanced (sub-slot) HARQ-ACK multiplexing on PUSCH (of Sec. 4.3 of R1-2007216) can be further discussed as part of AI 8.3.3 in this WI (but not as part of AI 8.3.1.1).
Agreements:
Study further at least the following schemes:
· SPS HARQ skipping for ‘skipped’ SPS PDSCH
· PUCCH repetition enhancements (at least for HARQ-ACK), e.g., sub-slot based, etc.
· Retransmission of cancelled HARQ
· SPS HARQ payload size reduction and / or skipping for ‘non-skipped’SPS PDSCH
· Type 1 HARQ codebook based on sub-slot PUCCH config
· PUCCH carrier switching for HARQ feedback
Companies are encouraged to provide detailed analysis and comparison accordingly
Final summary in:
R1-2007354 Feature lead summary #4 on Rel-17 HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
R1-2005432 Discussion on CSI feedback enhancements for eURLLC ZTE
· Proposal 1: Support both DL grant based A-CSI triggering and NACK based A-CSI triggering in Rel-17.
· Proposal 2: Support both CSI measurement based on CSI-RS and PDSCH in Rel-17.
· Proposal 3: For DL grant based or NACK based A-CSI triggering, A-CSI is transmitted in PUCCH.
· Proposal 4: For NACK based A-CSI triggering, A-CSI and HARQ-ACK are transmitted in the same PUCCH.
· Proposal 5: For DL grant based A-CSI triggering with CSI-RS based measurement, it needs to further study whether the A-CSI should be transmitted in the same PUCCH carrying HARQ-ACK.
· Proposal 6: It needs to further study how to determine the A-CSI feedback payload.
· Proposal 7: For DL-grant based A-CSI triggering, the processing timeline for PUCCH carrying A-CSI and HARQ-ACK in the same or separate PUCCH should be further studied.
Decision: The document is noted.
R1-2006140 CSI feedback enhancements for URLLC Samsung
· Proposal 1: Consider support of P/SP-CSI report with priority 1.
Decision: The document is noted.
R1-2005244 CSI feedback enhancements Huawei, HiSilicon
R1-2005281 CSI feedback enhancements for URLLC FUTUREWEI
R1-2005375 CSI feedback enhancements for Rel-17 URLLC vivo
R1-2005514 CSI Feedback Enhancements for IIoT/URLLC Ericsson
R1-2005552 CSI feedback enhancements for URLLC/IIoT use cases Nokia, Nokia Shanghai Bell
R1-2005570 Considerations on CSI feedback enhancements Sony
R1-2005634 CSI feedback enhancements for URLLC MediaTek Inc.
R1-2005702 CSI feedback enhancements CATT
R1-2005776 CSI feedback enhancement NEC
R1-2005870 CSI feedback enhancements in Release 17 URLLC/IIoT Intel Corporation
R1-2005930 CSI feedback enhancements Lenovo, Motorola Mobility
R1-2006059 Enhancement for CSI feedback OPPO
R1-2006071 CSI feedback enhancements for enhanced URLLC/IIoT InterDigital, Inc.
R1-2006208 Discussion on CSI feedback enhancements CMCC
R1-2006276 Discussion on CSI feedback enhancements Spreadtrum Communications
R1-2006315 Discussion on CSI feedback enhancements for URLLC LG Electronics
R1-2006343 Discussion on CSI feedback enhancements Panasonic Corporation
R1-2006515 CSI feedback enhancements for URLLC Apple
R1-2006573 CSI feedback enhancements for eURLLC Sharp, NICT
R1-2006729 Discussion on CSI feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
R1-2006800 CSI enhancement for IOT and URLLC Qualcomm Incorporated
[102-e-NR-IIOT_URLLC_enh-02] – Moonil (InterDigital)
Email discussions/approval
· By 8/21 – high priority
· By 8/27 – medium
R1-2007064 Feature lead summary #1 on CSI feedback enhancements for Rel-17 URLLC/IIoT Moderator (InterDigital)
R1-2007110 Feature lead summary #2 on CSI feedback enhancements for Rel-17 URLLC/IIoT Moderator (InterDigital)
From GTW session on August 24th,
Agreement:
· CSI feedback enhancement for Multi-TRP transmission is not to be discussed further under IIoT/URLLC enhancement WI
Agreements:
Agreements:
From GTW session on August 28th,:
Agreements:
· Consider Table 1 as baseline assumption for system level simulation for evaluating CSI enhancement schemes
o The uses cases in Table 1 is for simulation purposes and it does not preclude a CSI enhancement scheme which is beneficial for the other URLLC use cases
· No baseline assumption is used for link level simulation
o Companies are encouraged to use one of LLS assumption tables in Section A.3 in TR38.824 for any link level simulation
Table 1. Baseline SLS assumption for CSI enhancement schemes in URLLC/IIoT
|
Parameters |
Values |
|
Performance metric |
Option-1 (section 5.1 of TR 38.824)
Additional metrics (it is up to company to bring results with additional metric): · MCS prediction error (e.g., difference of a scheduled MCS and an ideal MCS) · DL/UL signaling overhead · CCDF of latency samples from all UEs · BLER of 1st transmission · Resource utilization · Spectral efficiency |
|
Use cases |
Following two use cases can be considered for new triggering method and new reporting. Companies are encouraged to evaluate the following cases in descending priority: · Rel-15 enabled use case (e.g. AR/VR) in TR 38.824 o Reliability: 99.999 o Latency: 4ms (200bytes) o Traffic mode: FTP model 3 (100p/s) · Factory automation in TR 38.824 o Reliability: 99.9999 o Latency: 1ms (32bytes) o Traffic mode: Periodic deterministic traffic model with arrival interval 2ms · Rel-15 enabled use case (e.g. AR/VR) in TR 38.824 o Reliability: 99.999 o Latency: 1ms (32bytes) o Traffic mode: FTP model 3 (100p/s) o Assumptions for eMBB and URLLC UEs sharing the same carrier is used (as in A2.5 of TR 38.824) |
|
Simulation assumptions |
Following simulation assumption is used based on the use case selected: · Rel-15 enabled use case with UMa (Table A.2.4-1 in TR 38.824) · Factory automation at 4GHz (Table A.2.2-1 in TR38.824) with following update: o Channel model is replaced with InF (InF-DH) in TR 38.901 § Companies can bring results with other InF scenarios additionally o Layout is replaced with BS deployment in Table 7.8-7 in TR 38.901 |
|
Transmission scheme |
Multiple antenna ports Tx scheme · Companies report the details of Tx scheme used |
Final summary in:
R1-2007286 Feature lead summary#3 on CSI feedback enhancements for Rel-17 URLLC/IIoT Moderator (InterDigital)
R1-2006247 On UL Enhancements for IIoT/URLLC in Unlicensed Controlled Environment Nokia, Nokia Shanghai Bell
· NR/NR-U CG enhancements harmonization:
o Proposal 1: Two operation modes can be considered independently; NR IIoT Rel-16 based CG with NR based HARQ procedure and without CG-UCI, and NR-U based CG including CG-UCI and possibility of UE COT sharing.
o Proposal 2: PUSCH repetitions type-B should be supported for unlicensed band operation when using NR IIoT Rel-16 based CG, without NR-U specific enhancements. FFS: required spec changes, if any.
o Proposal 3: The use of PUSCH repetition type-B together with NR-U based multi-slot allocations should not be considered.
o Proposal 4: Frequency hopping can be considered for UL resource allocation type 2 in case of wideband (>20 MHz) operation.
o Proposal 5: PHY prioritization of HARQ-ACKs introduced in Rel-16 is supported also with NR-U CG. Interaction of CG-UCI and HARQ-ACK codebooks of different priorities is FFS.
· On the support for UE-initiated COT for FBE
o Proposal 6: At least the duration of the UE FFP can be different from the duration of the gNB FFP. FFS whether the UE FFP duration is explicitly configured, or implicitly determined based on other configurations such as RACH configuration, UL CG configuration, etc.
o Proposal 7: Support flexible determination of the start the UE FFP by the UE based on gNB configuration.
o Proposal 8: No restrictions to UE FFP configuration based on gNB FFP configuration are introduced other than what is already specified in TS 37.213 regarding UL transmissions within the idle period of the gNB FFP.
o Proposal 9: A UE should be able to determine exclusively from information in the scheduling DCI, whether a scheduled PUSCH transmission should be transmitted according to shared gNB COT or UE-initiated COT.
Decision: The document is noted.
R1-2006316 Discussion on unlicensed band URLLC/IIOT LG Electronics
· Proposal 1: Consider gNB-controlled UE-initiated COT mechanisms for FBE based U-band environments, in order to avoid potential collision/blocking between UE’s UL transmission and gNB’s essential DL transmission.
· Proposal 2: Consider configuration of unaligned FFP timing between the FFP stating with gNB-initiated COT and the FFP starting with UE-initiated COT.
· Proposal 3: Consider dynamic indication of whether to allow UE-initiated COT for the next FFP, based on the transmission of an UE-common DCI.
· Proposal 4: Consider new equation for determining HARQ process ID (e.g., based on NR-U CG resource allocation) in order to support multiple TB transmission per period.
· Proposal 5: Consider to adopt PUSCH repetition type B for NR-U CG resource allocation to support flexible resource allocation.
· Proposal 6: Consider to handle the orphan symbol created after segmentation under some condition in unlicensed band to avoid unnecessary LBT/CAP procedure.
Decision: The document is noted.
R1-2005433 Discussion on unlicensed band URLLC/IIoT ZTE
R1-2005515 Enhancements for IIoT/URLLC on Unlicensed Band Ericsson
R1-2005571 Enhancements for unlicensed band URLLC/IIoT Sony
R1-2005635 On the enhancements for unlicensed band URLLC/IIoT MediaTek Inc.
R1-2005703 Enhancements for unlicensed band URLLC/IIoT CATT
R1-2005736 UL transmission for URLLC on unlicensed band Beijing Xiaomi Software Tech
R1-2005768 Enhancements for unlicensed band URLLC/IIoT TCL Communication Ltd.
R1-2005871 Uplink enhancements for URLLC operating in unlicensed spectrum Intel Corporation
R1-2005931 Enhancements for unlicensed band URLLC/IIoT Lenovo, Motorola Mobility
R1-2006060 Enhancement for unlicensed band URLLC/IIoT OPPO
R1-2006072 Enhancements for unlicensed band URLLC/IIoT InterDigital, Inc.
R1-2006141 Enhancements for unlicensed band URLLC/IIoT Samsung
R1-2006277 Discussion on enhancements for unlicensed band URLLC/IIoT Spreadtrum Communications
R1-2006344 Enhancements for unlicensed band URLLC/IIoT Panasonic Corporation
R1-2006356 Discussion on enhancements for URLLC in unlicensed bands ETRI
R1-2006516 URLLC uplink enhancements for unlicensed spectrum Apple
R1-2006574 Potential enhancements for unlicensed band URLLC/IIoT Sharp
R1-2006651 Considerations for unlicensed IIoT Charter Communications
R1-2006730 Discussion on enhancements for unlicensed band URLLC NTT DOCOMO, INC.
R1-2006801 Uplink enhancements for URLLC in unlicensed controlled environments Qualcomm Incorporated
R1-2006888 Discussion on enhancement for unlicensed URLLC/IIoT WILUS Inc.
R1-2006929 Uplink enhancements for URLLC in unlicensed controlled environments Huawei, HiSilicon
[102-e-NR-IIOT_URLLC_enh-03] – Sorour (Ericsson)
Email discussions/approval
· By 8/21 – high priority
· By 8/27 – medium
R1-2007069 Summary#1 on enhancements for unlicensed band URLLC/IIoT for R17 Moderator (Ericsson)
R1-2007228 Summary#2 on enhancements for unlicensed band URLLC/IIoT for R17 Moderator (Ericsson)
R1-2007301 Summary#3 on enhancements for unlicensed band URLLC/IIoT for R17 Moderator (Ericsson)
From GTW sessions on August 25th/August 26th,
Agreements:
· For semi-static channel access mode,
o If sensing is needed, it is performed immediately before the configured/scheduled transmission opportunity.
o For operation with semi-static channel access, the Rel-16 random starting offsets for UL configured grants with Full BW allocation when UE initiates a COT, is not supported.
Agreements:
· For semi-static channel access mode,
o When gNB operates as an initiating device
§ The gNB is not allowed to transmit during the idle period of any FFP associated with the gNB in which the gNB initates a COT
o When a UE operates as an initiating device
§ The UE is not allowed to transmit during the idle period of any FFP associated with the UE in which the UE initates a COT
o When a UE shares a COT initiated by the gNB during an FFP associated with the gNB
§ The UE is not allowed to transmit during the idle period of that FFP in which the UE shares the COT initiated by the gNB
o When the gNB shares a COT initiated by a UE during an FFP associated with the UE
§
The gNB is not allowed to transmit
during the idle period of that the FFP in which the gNB shares the COT initiated
by the UE
o FFS whether/how to support additional restrictions to the idle period
Agreements:
· For semi-static channel access mode, support using the transmission of any scheduled/configured UL channel/signal to initiate a COT by a UE in RRC_CONNECTED mode
o FFS the case when the UE is IDLE/INACTIVE mode
Agreements:
· A UE initiates a COT in an FFP associated with the UE, if the UE transmits a UL transmission burst starting at the beginning of the FFP and ending at any symbol before the FFP’s idle period after a successful CCA of 9us immediately before the UL transmission burst.
Agreements:
· At least for FBE, configuration of (cg-RetransmissionTimer) should not be mandated when configured grant Type 1 or Type 2 are configured on unlicensed spectrum.
Conclusion:
Further study and decide how to harmonize the CG features for Rel-16 URLLC and Rel-16 NR-U. Table 1 in R1-2005376 can be used as a starting point for the corresponding discussion and decision.
R1-2005376 Enhancements for unlicensed band URLLC/IIoT vivo
Agreements:
· Conditions on the channel access procedures with respect to sensing duration and transmission gap for UE-initiated COT with UE-to-gNB COT sharing is similar as those for gNB initiated COT and gNB-to-UE COT sharing in Rel-16 by exchanging UE and gNB roles.
Agreements:
· UE-to- gNB COT sharing in semi-static channel access mode is supported.
o The gNB determines a COT in an FFP associated to a UE, that is initiated by the UE, if the gNB detects a UL transmission from the UE starting from the beginning of the FFP and ending before the idle period of the FFP.
§ FFS details
o When the gNB determines a UE has initiated a COT in an FFP associated to the UE, the gNB can transmit within the FFP and before the idle period corresponding to the FFP.
§ FFS whether/how UE to gNB COT sharing when the gap is >16us
R1-2007332 Summary#4 on enhancements for unlicensed band URLLC/IIoT for R17 Moderator (Ericsson)
From GTW session on August 28th,
Agreements:
For semi-static channel access mode,
· Start of FFP for UE-initiated COT can be different from the start of FFP for gNB-initiated COT.
· FFS: FFP Periodicity for UE-initiated COT can be different from the FFP periodicity for gNB-initiated COT.
Agreements:
For semi-static channel access mode,
· FFP parameters for UE-initiated COT can be provided to the UE by at least dedicated RRC signaling.
o FFS on to be provided by SIB-1
· FFS whether the UE FFP periodicity is explicitly configured, or implicitly determined based on other higher layer parameters
Final summary in:
R1-2007391 Summary#5 on enhancements for unlicensed band URLLC/IIoT for R17 Moderator (Ericsson)
R1-2005516 Intra-UE Multiplexing/Prioritization Enhancements for IIoT/URLLC Ericsson
· Proposal 1: Allow multiplexing of UCI of different priorities only if all involved PUCCHs are contained within the same sub-slot.
· Proposal 2: When a PUCCH covers several sub-slots and overlaps with sub-slot level PUCCH, drop low priority UCI as in Rel. 16.
· Proposal 3: Ensure (re-)transmission of low priority HARQ-ACK feedback in case of collision with high priority UL transmissions is supported irrespective of sub-slot configuration.
· Proposal 4: Consider at least the following solutions with potential enhancement for enabling (re-)transmission of low priority HARQ-ACK feedback in case of collision
o Reusing One-shot HARQ-ACK request with potential enhancements to reduce size of HARQ-ACK codebook
o Reusing UE behavior for NNK1 by assuming NNK1 for a dropped eMBB HARQ-ACK codebook after cancellation
o Reusing principles for enhanced Type-2 HARQ-ACK codebook to retransmit dropped eMBB HARQ-ACK codebook in next PUCCH
· Proposal 5: For collision handling between high priority CG and low priority DG: PHY layer can make the prioritization so that the UE is expected to transmit the PUSCH corresponding to the configured grant, and cancel the overlapping low priority PUSCH scheduled by the PDCCH at latest starting at the first symbol of the PUSCH corresponding to the configured grant.
· Proposal 6: For collision handling between high priority DG and low priority CG: PHY layer can make the prioritization so that the UE is expected to cancel the overlapping low priority CG PUSCH by the first overlapping symbol at the latest. Further, a UE expects that the first overlapping symbol of the high priority DG PUSCH is not earlier than Tproc,2+d1after the last symbol of the PDCCH with the DCI format scheduling the high priority channel.
· Proposal 7: Reintroduce the text above to Subclause 6.1 of TS 38.214.
Decision: The document is noted.
R1-2006802 Intra-UE multiplexing and prioritization for IOT and URLLC Qualcomm Incorporated
· Proposal 1: Study modulation order and code rate selection for UCI multiplexed on PUSCH based on beta scaled spectrum efficiency of UCI.
· Proposal 2: when low priority HARQ-ACK overlap with high priority PUCCH/PUSCH, bundle the low priority HARQ-ACK codebook into X bits (e.g. X=1), append the X bits to the end of high priority HARQ-ACK codebook (if exist) and jointly encode them, and further multiplex the jointed encoded codeword on an overlapping high priority PUSCH (if exist).
· Proposal 3: when high priority HARQ-ACK overlap with low priority PUSCH, high priority HARQ-ACK is multiplexed on low priority PUSCH by puncturing the low priority PUSCH.
· Proposal 4: Adopt the collision resolution in Table 1 for collision between different priority PUCCH/PUSCH transmissions.
· Proposal 5: RAN1 should discuss which of the following cases should be supported.
o Case 1: high-priority DG-PUSCH collide with low-priority CG-PUSCH
o Case 2: low-priority DG-PUSCH collide with high-priority CG-PUSCH
· Proposal 6: The cancellation time for CG-PUSCH and DG-PUSCH collision resolution does not reuse Rel-16 cancellation time for PUCCH/PUCCH or PUCCH/PUSCH collision.
· Proposal 7: Support simultaneous PUCCH and PUSCH transmission on different CCs at least in inter-band CA.
· Proposal 8: Support multiplexing of overlapped SPS A/N repetitions with different priorities.
· Proposal 9: UE is not expected high priority SPS A/N overlapped with dynamically scheduled PDSCH or CSI-RS.
o At least when the UL feedback of PDSCH or CSI-RS has low priority.
Decision: The document is noted.
R1-2005245 Intra-UE multiplexing enhancements Huawei, HiSilicon
R1-2005377 Intra-UE Multiplexing/Prioritization for Rel-17 URLLC vivo
R1-2005434 Discussion on enhanced intra-UE multiplexing ZTE
R1-2005572 Considerations on intra-UE UL multiplexing & prioritisation Sony
R1-2005636 Methods for intra-UE multiplexing and prioritization MediaTek Inc.
R1-2005704 Intra-UE multiplexing and prioritization CATT
R1-2005737 Intra-UE multiplexing/prioritization Beijing Xiaomi Software Tech
R1-2005777 Discussion on Intra-UE prioritization and multiplexing NEC
R1-2005872 Intra-UE multiplexing and prioritization in Release 17 URLLC/IIoT Intel Corporation
R1-2005932 Intra-UE multiplexing enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2006061 Enhancements on intra-UE multiplexing/prioritization OPPO
R1-2006073 Intra-UE multiplexing and prioritization InterDigital, Inc.
R1-2006142 Uplink intra-UE multiplexing and prioritization Samsung
R1-2006209 Discussion on intra-UE multiplexing/prioritization CMCC
R1-2006251 Discussion on Intra-UE Multiplexing/Prioritization Spreadtrum Communications
R1-2006317 Discussion on Intra-UE multiplexing/prioritization LG Electronics
R1-2006340 On Rel-17 UL intra-UE prioritization and multiplexing enhancements for traffic with different priorities Nokia, Nokia Shanghai Bell
R1-2006345 Discussion on Intra-UE multiplexing and prioritization of different priority Panasonic Corporation
R1-2006517 Intra-UE Multiplexing/Prioritization for URLLC Apple
R1-2006575 Enhancements on intra-UE multiplexing and prioritization Sharp
R1-2006656 Discussion on intra-UE multiplexing ITRI
R1-2006731 Discussion on intra-UE multiplexing/prioritization for Rel.17 URLLC NTT DOCOMO, INC.
R1-2006870 Intra-UE multiplexing for URLLC Potevio
R1-2006889 Discussion on Intra-UE multiplexing/prioritization for IIoT/URLLC WILUS Inc.
R1-2007055 Summary#1 on Intra-UE Multiplexing/Prioritization for R17 IIoT/URLLC Moderator (OPPO)
[102-e-NR-IIOT_URLLC_enh-04] – Jia (OPPO)
Email discussions/approval
· By 8/21 – high priority
· By 8/27 – medium
R1-2007075 Summary#1 of email thread [102-e-NR-IIOT_URLLC_enh-04] Moderator (OPPO)
Agreements:
Support multiplexing for following scenarios in R17:
· Multiplexing a high-priority HARQ-ACK and a low-priority HARQ-ACK into a PUCCH in R17.
· Multiplexing a low-priority HARQ-ACK and a high-priority SR into a PUCCH for some HARQ-ACK/SR PF combinations (FFS applicable combinations).
· Multiplexing a low-priority HARQ-ACK, a high-priority HARQ-ACK and a high-priority SR into a PUCCH.
For the above multiplexing scenarios,
· FFS conditions, if needed, for the multiplexing, e.g
o Whether to support multiplexing between different resources not confined within a sub-slot.
o Whether to support multiplexing in case a PUCCH overlaps with more than one PUCCH.
o Timeline requirements.
· FFS: details, if needed, of the multiplexing scheme, e.g.
o How to minimize impact on the latency for high-priority HARQ-ACK.
o How to determine the PUCCH resource used for multiplexing (e.g. HP or LP PUCCH resource, or a dedicated PUCCH resource for the multiplexing).
o How to multiplex the HARQ-ACK bits (e.g. multiplexing, bundling).
o How to encode the UCIs with different priorities (e.g. separate coding vs. joint coding)
o How to guarantee the target code rate (e.g. payload control, multiplexing priority, LP HARQ-ACK compression/compaction).
o Explicit indication for enabling multiplexing.
o Multiplexing rule and order (e.g. HP/LP multiplexing is after resolving collision within the same priority).
Agreements:
Support multiplexing for following scenarios in R17:
· Multiplexing a low-priority HARQ-ACK in a high-priority PUSCH (conveying UL-SCH only).
· Multiplexing a high-priority HARQ-ACK in a low-priority PUSCH (conveying UL-SCH only)
· Multiplexing a low-priority HARQ-ACK, a high-priority PUSCH conveying UL-SCH, a high-priority HARQ-ACK and/or CSI.
· Multiplexing a high-priority HARQ-ACK, a low-priority PUSCH conveying UL-SCH, a low-priority HARQ-ACK and/or CSI.
For the above multiplexing scenarios,
· Support separate configurations of at least beta-offset values (FFS for alpha) for multiplexing with different priority combinations.
o FFS for other separate configurations.
o FFS: value range of beta-offset (e.g. <1).
· FFS the conditions, if needed, for multiplexing, e.g.
o FFS: Whether to support multiplexing in case a PUCCH/PUSCH overlaps with more than one PUCCH/PUSCH.
o Timeline requirements.
· FFS: details, if needed, of the multiplexing scheme, e.g.
o How to minimize impact on the latency for high-priority HARQ-ACK.
o How to multiplex the HARQ-ACK bits (e.g. multiplexing, bundling)?
o How to encode the UCIs with different priorities (e.g. separate coding vs. joint coding).
o How to guarantee the target code rate (e.g. payload control, multiplexing priority, LP HARQ-ACK compression/compaction).
o Explicit indication for multiplexing.
o Multiplexing rule and order (e.g. HP/LP multiplexing is after resolving collision within the same priority).
o How to handle multiplexing of UCI of different priorities and CG-UCI in a CG-PUSCH
Agreements:
Support PHY prioritization for the case where low-priority DG-PUSCH collides with high-priority CG-PUSCH in R17.
· FFS details
· Clarify R16 baseline if needed.
Agreements:
Support simultaneous PUCCH/PUSCH transmissions on different cells at least for inter-band CA.
· FFS how to trigger this function.
· FFS for intra-band CA.
Including any RAN1 involvement in propagation delay compensation enhancements (including mobility issues, if any).
R1-2005517 Propagation Delay Compensation Enhancements for Time Synchronization Ericsson
· Proposal 1: RAN1 to adopt a target uncertainty goal of no more than 200ns for each instance of 5G reference time relayed from a gNB to a UE.
· Proposal 2: Investigate whether the legacy RTT method or an enhanced RTT method is most suitable for determining the downlink propagation delay value, which is then used to adjust the 5G reference time value sent from a gNB to a UE.
· Proposal 3: For the selected RTT method, identify the sources of uncertainty involved and potentially requiring mitigation to reach the 200ns uncertainty target.
Decision: The document is noted.
R1-2005378 Other issues for Rel-17 URLLC vivo
R1-2005435 Discussion on propagation delay compensation enhancements ZTE
R1-2005705 Discussion on propagation delay compensation enhancements CATT
R1-2006062 Enhancement for Propagation Delay Compensation OPPO
R1-2006143 Discussion for propagation delay compensation enhancements Samsung
R1-2006341 Discussion on RAN1 involvement in propagation delay compensation Nokia, Nokia Shanghai Bell
R1-2006357 On processing time for shared COT acquisition for unlicensed URLLC in FBE ETRI
R1-2006518 Discussion on Orphan symbol handling for unlicensed spectrum Apple
R1-2006803 Enhancements for support of time synchronization for enhanced IIoT and URLLC Qualcomm Incorporated
R1-2006930 Enhancements for support of time synchronization Huawei, HiSilicon
[102-e-NR-IIOT_URLLC_enh-05] – Chengyan (Huawei)
Email discussions/approval by 8/26
R1-2007068 Summary#1 of email discussion [102-e-NR-IIOT_URLLC_enh-05] Moderator (Huawei)
Decision: As per email decision posted on August 26th,
Agreements:
· Take the following use cases as the representative use cases for further study on propagation delay compensation enhancements in Rel-17.
|
User-specific clock synchronicity accuracy level |
Number of devices in one Communication group for clock synchronisation |
5GS synchronicity budget requirement (note) |
Service area |
Scenario |
|
2 |
Up to 300 UEs |
≤900 ns |
≤ 1000 m x 100 m |
- Control-to-control communication for industrial controller |
|
4 |
Up to 100 UEs |
<1 µs |
< 20 km2 |
- Smart Grid: synchronicity between PMUs |
Agreement:
· ±8*64*Tc/2m as the TA indicating error is assumed in the evaluation.
Decision: As per email decision posted on August 27th,
Agreements:
For 5GS synchronicity budget requirement,
· One Uu interface is assumed for smart grid.
· Two Uu interfaces are assumed for control-to-control.
Agreements:
For BS transmit timing error, further study the following three options:
· Option 1: 65 ns
· Option 2:±130ns for the indoor scenario and ±200ns for the smart grid scenario
· Option 3:82.5 ns
Agreement: The value defined in Table 7.1.2-1 for initial transmit timing error (Te) in TS 38.133 should be considered for evaluation of the time synchronization.
Agreement: Asymmetry between downlink and uplink channel for control-to-control scenario is not considered.
Agreement: 100 ns is assumed for BS detecting error.
Agreement: Timing advance adjustment accuracy defined in Table 7.3.2.2-1 in TS 38.133 is assumed for evaluation of the time synchronization.
Agreement: Both 15 kHz and 30 kHz are assumed for both control-to-control and smart grid for evaluation of the time synchronization.
Agreements:
Send an LS to RAN2 with the content including
· Inform RAN2 the two representative use cases concluded in RAN1 for further study;
· Ask RAN2 for input about Uu interface error budget for each of the two use cases;
Decision: As per email decision posted on August 28th,
Agreements:
The following options for propagation delay compensation are further studied in RAN1
· Option 1: TA-based propagation delay
o Option 1a: Propagation delay estimation based on legacy Timing advance (potentially with enhanced TA indication granularity).
o Option 1b: Propagation delay estimation based on timing advanced enhanced for time synchronization (as 1a but with updated RAN4 requirements to TA adjustment error and Te)
o Option 1c: Propagation delay estimation based on a new dedicated signaling with finer delay compensation granularity (Separated signaling from TA so that TA procedure is not affected)
· Option 2: RTT based delay compensation:
o Propagation delay estimation based on an RAN managed Rx-Tx procedure intended for time synchronization (FFS to expand or separate procedure/signaling to positioning).
R1-2007445 Draft LS on propagation delay compensation enhancements Huawei
Decision: The draft LS is endorsed. Final LS is approved in R1-2007446.
Please refer to RP-201310 for detailed scope of the WI
R1-2007707 HARQ-ACK Enhancements for IIoT/URLLC Ericsson
Proposal 8:Support PUCCH repetition based on UCI type through configuration of PUCCH resource.
Proposal 9: Support PUCCH repetition of PUCCH formats 0 and 2.
Proposal 11: Support Type-3 HARQ-ACK codebook with priority indication in the triggering DCI.
· Study other methods for size reduction for Type 3 HARQ-CB
Proposal 13: Do not support SPS HARQ payload size reduction.
Proposal 14: Support
Type-1 HARQ codebook for sub-slot HARQ-ACK by updating the pseudo code for
determining a set of occasions for candidate PDSCH reception where the ratio is changed to , where N is the number of sub-slots in an UL slot.
Proposal 15: Do not support dynamic PUCCH carrier switching.
Decision: The document is noted.
R1-2009257 HARQ-ACK enhancement for IOT and URLLC Qualcomm Incorporated
· Proposal 1: gNB explicitly requests via DCI for a UE to transmit modified HARQ-ACK codebook Type 3, in which the UE reports HARQ-ACK feedback for all SPS HARQ-IDs in a given time window.
· Proposal 2: Study the following two options for empty SPS indication.
o Option 1: Explicit DCI indicating a single or multiple empty (‘skipped’) SPS PDSCH occasion.
o Option 2: send a special DMRS sequence on nominal DMRS OFDM symbols in a SPS occasion to indicate the SPS occasion is empty.
· Proposal 3: Support dynamic bundling/compression of UCI.
· Proposal 4: Support modified HARQ-ACK codebook Type 3 for retransmission of cancelled HARQ-ACK.
· Proposal 5: Support compress multiple messages in HARQ-ACK codebook with small probability into a single message, to reduce HARQ-ACK payload size.
· Proposal 6: Support NACK only HARQ-ACK feedback in which only NACK transmission takes place and ACK is skipped.
· Proposal 7: Adopt a static rule to determine the carrier to transmit HARQ-ACK with PUCCH carrier switch.
· Proposal 8: Use MAC-CE to switch between multiple sub-slot configurations for HARQ-ACK feedback.
Decision: The document is noted.
R1-2007565 UE feedback enhancements for HARQ-ACK Huawei, HiSilicon
R1-2007655 HARQ-ACK enahncements for Rel-17 URLLC vivo
R1-2007789 UE feedback enhancements for HARQ-ACK TCL Communication Ltd.
R1-2007849 UE feedback enhancements for HARQ-ACK CATT
R1-2007900 HARQ feedback enhancement for URLLC Beijing Xiaomi Software Tech
R1-2008007 Discussion on UE feedback enhancements for HARQ-ACK CMCC
R1-2008057 Discussion on UE feedback enhancement for HARQ-ACK LG Electronics
R1-2008159 HARQ-ACK feedback enhancements for Rel-17 URLLC/IIoT Samsung
R1-2008279 HARQ-ACK enhancements for Rel-17 URLLC/IIoT OPPO
R1-2008355 Considerations in HARQ-ACK enhancements for URLLC Sony
R1-2008460 Discussion on UE feedback enhancements for HARQ-ACK Apple
R1-2008821 Discussion on HARQ-ACK enhancements for eURLLC ZTE
R1-2008842 HARQ-ACK Feedback Enhancements for URLLC/IIoT Nokia, Nokia Shanghai Bell
R1-2008941 UE feedback enhancements for HARQ-ACK NEC Corporation
R1-2008952 Discussion on UE feedback enhancements for HARQ-ACK Panasonic Corporation
R1-2008984 Discussion on prioritized UE HARQ feedback enhancements for URLLC/IIoT Intel Corporation
R1-2009011 UE feedback enhancements for HARQ-ACK ETRI
R1-2009053 Discussion on UE feedback enhancements for HARQ-ACK Asia Pacific Telecom co. Ltd
R1-2009063 On UE feedback enhancements for HARQ-ACK MediaTek Inc.
R1-2009083 HARQ-ACK enhancements for DL SPS InterDigital, Inc.
R1-2009101 HARQ-ACK feedback enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2009133 UE feedback enhancements for HARQ-ACK Sharp
R1-2009140 UE feedback enhancements for HARQ-ACK China Unicom
R1-2009148 Discussion on necessity and support of Physical Layer feedback enhancements Spreadtrum Communications
R1-2009182 Discussion on HARQ-ACK feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
R1-2009246 Discussion on HARQ-ACK enhancement for URLLC/IIoT WILUS Inc.
[103-e-NR-IIoT-URLLC-01] – Klaus (Nokia)
Email discussion/approval for UE feedback enhancements for HARQ-ACK
R1-2009566 Moderator summary #1 on Rel-17 HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT (AI 8.3.1.1) Moderator (Nokia)
From GTW sessions:
Agreements: To address the issue of SPS HARQ-ACK dropping for TDD systems, focus on the following two options:
Decision: As per email decision posted on Nov.13th,
Agreement: In the studies on PUCCH carrier switching for HARQ-ACK, PUCCH carrier switching for different cells operated is considered only for cells that are part of the active UL CA configuration.
Agreements: For the studies on SPS HARQ skipping for skipped SPS PDSCH, the further discussions should focus on the following reduced sets methods:
Agreements: For the studies on SPS HARQ payload size reduction (of non-skipped SPS PDSCH), the further discussions should focus on the following reduced sets of methods:
Final summary in:
R1-2009789 Moderator summary on Rel-17 HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT (AI 8.3.1.1) – end of meeting Moderator (Nokia)
R1-2008160 CSI feedback enhancements for URLLC Samsung
· Proposal 1: A-CSI report triggering by a DCI format scheduling a PDSCH reception is not further considered.
· Proposal 2: If an enhancement to CSI report triggering is to be considered in the WI, it should be limited only to using a GC-DCI format as for SRS triggering.
· Proposal 3: Whether/how to support outer-loop link adaptation for URLLC using soft HARQ-ACK values can be further considered subject to confirming applicability and resolving associated drawbacks.
· Proposal 4: Enable use of different MCS tables for PDSCH receptions corresponding to different priority values of a DCI format.
· Proposal 5: Support accurate MCS selection for PDCCH by providing a CSI report for a corresponding CORESET.
Decision: The document is noted.
R1-2007539 CSI feedback enhancements for URLLC FUTUREWEI
R1-2007566 CSI feedback enhancements Huawei, HiSilicon
R1-2007656 CSI feedback enhancements for Rel-17 URLLC vivo
R1-2007708 CSI Feedback Enhancements for IIoT/URLLC Ericsson
R1-2007850 CSI feedback enhancements CATT
R1-2008008 Discussion on CSI feedback enhancements CMCC
R1-2008058 Discussion on CSI feedback enhancements for URLLC LG Electronics
R1-2008107 Discussion on CSI feedback enhancements Spreadtrum Communications
R1-2008280 CSI feedback enhancements for URLLC OPPO
R1-2008356 Considerations in CSI feedback enhancements Sony
R1-2009768 Discussion on CSI feedback enhancements for URLLC/IIoT Apple (rev of R1-2008461)
R1-2008495 CSI Feedback Enhancements for IIoT/URLLC III
R1-2008822 Discussion on CSI feedback enhancements for eURLLC ZTE
R1-2008847 CSI feedback enhancement NEC
R1-2008862 CSI feedback enhancements for URLLC/IIoT use cases Nokia, Nokia Shanghai Bell
R1-2008936 CSI feedback enhancements for enhanced URLLC/IIoT InterDigital, Inc.
R1-2008953 Discussion on CSI feedback enhancements Panasonic Corporation
R1-2008985 Discussion on prioritized CSI feedback enhancements for URLLC/IIoT Intel Corporation
R1-2009064 CSI feedback enhancements for URLLC MediaTek Inc.
R1-2009102 CSI feedback enhancements for URLLC/IIoT Lenovo, Motorola Mobility
R1-2009134 CSI feedback enhancements for eURLLC Sharp, NICT
R1-2009183 Discussion on CSI feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
R1-2009258 CSI enhancement for IOT and URLLC Qualcomm Incorporated
R1-2009455 Feature lead summary #1 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
[103-e-NR-IIoT-URLLC-02] – Moonil (InterDigital)
Email discussion/approval for CSI feedback enhancements
R1-2009558 Feature lead summary #2 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
Agreements
· No change of CSI processing time relative to Rel-16 CSI in this WI
· CSI processing time specific to a new CSI reporting quantity/type (if supported) can be studied
R1-2009649 Feature lead summary #3 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
Agreement:
Agreements:
For Case-1 New reporting, the following candidate schemes have been identified to address the fast interference change over time. Continue studying with focus on the identified schemes below for further study and evaluation.
Companies are encouraged to investigate the above schemes, aiming for down-selection in RAN1#104-e
Final summary in:
R1-2009775 Feature lead summary #4 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
R1-2008357 Considerations in unlicensed URLLC Sony
· Proposal 1: The FFP duration (period) for the gNB and UE can be configured to be different.
· Proposal 2: The starting FFP offset and FFP duration are independently configured for each UE.
· Proposal 3: A UE can be configured to support multiple FFP configurations.
· Proposal 4: Consider introducing gaps between two FFPs of a UE where the UE cannot initiate a COT.
· Proposal 5: Allow a UE that has initiated a COT to release ownership of the COT to the gNB.
· Proposal 6: UE initiated COT for semi-static channel access is supported in Idle Mode.
· Proposal 7: Harmonisation for multiple CG configurations is not required, since both Rel-16 URLLC and NR-U already support multiple CG configurations.
· Proposal 8: CG-UCI is supported in Rel-17 unlicensed URLLC.
· Proposal 9: The parameters “cg-nrofPUSCH-InSlot-r16” and “cg-nrofSlots-r16” should be used in Rel-17 unlicensed URLLC.
· Proposal 10: Cross-slot transmission occasion (TO) configuration should be considered if cross-slot TO and PUSCH segmentation are supported.
· Proposal 11: Rel-17 unlicensed URLLC supports PUSCH segmentation.
· Proposal 12: Rel-17 unlicensed URLLC supports CG-DFI.
· Proposal 13: The parameter “enableConfiguredUL” should always be supported in Rel-17 unlicensed URLLC.
· Proposal 14: If some other URLLC parameters (e.g. Type B repetition) are enabled, the parameter “enableConfiguredUL” should also be enabled.
· Proposal 15: Rel-17 unlicensed URLLC should support L1 priority indication in CG-PUSCH.
Decision: The document is noted.
R1-2007551 UE initiated COT for FFP FUTUREWEI
R1-2007568 Uplink enhancements for URLLC in unlicensed controlled environments Huawei, HiSilicon
R1-2007657 Enhancements for unlicensed band URLLC/IIoT vivo
R1-2007709 Enhancements for IIoT/URLLC on Unlicensed Band Ericsson
R1-2007851 Enhancements for unlicensed band URLLC/IIoT CATT
R1-2007885 Enhancements for unlicensed band URLLC/IIoT TCL Communication Ltd.
R1-2007902 Enhancement for unlicensed band URLLC IIoT Beijing Xiaomi Software Tech
R1-2008059 Discussion on unlicensed band URLLC/IIOT LG Electronics
R1-2008108 Discussion on enhancements for unlicensed band URLLCIIoT Spreadtrum Communications
R1-2008161 Enhancements for unlicensed band URLLC/IIoT Samsung
R1-2008281 Enhancements for unlicensed band URLLC/IIoT OPPO
R1-2008462 URLLC uplink enhancements for unlicensed spectrum Apple
R1-2008568 UL enhancements for IIoT/URLLC in unlicensed controlled environment Nokia, Nokia Shanghai Bell
R1-2008823 Discussion on unlicensed band URLLC/IIoT ZTE
R1-2008834 Unlicensed aspects for IIoT Charter Communications
R1-2008891 Enhancements for unlicensed band URLLC/IIoT NEC
R1-2008954 Enhancements for unlicensed band URLLC/IIoT Panasonic Corporation
R1-2008986 Enhancements to Enable URLLC/IIoT in Unlicensed Band Intel Corporation
R1-2009012 Enhancements for unlicensed band URLLC/IIoT ETRI
R1-2009065 On the enhancements for unlicensed band URLLC/IIoT MediaTek Inc.
R1-2009084 Enhancements for unlicensed band URLLC/IIoT InterDigital, Inc.
R1-2009103 Enhancements for unlicensed band URLLC/IIoT Lenovo, Motorola Mobility
R1-2009135 Enhancements for unlicensed band URLLC/IIoT Sharp
R1-2009184 Discussion on enhancements for unlicensed band URLLC NTT DOCOMO, INC.
R1-2009247 Discussion on enhancement for unlicensed URLLC/IIoT WILUS Inc.
R1-2009259 Uplink enhancements for URLLC in unlicensed controlled environments Qualcomm Incorporated
R1-2009492 Summary#1 on Enhancements for URLLC/IIoT on Unlicensed Band Moderator (Ericsson)
[103-e-NR-IIoT-URLLC-03] – Sorour (Ericsson)
Email discussion/approval for enhancements for unlicensed band URLLC/IIoT
R1-2009601 Summary#2 on Enhancements for URLLC/IIoT on Unlicensed Band Moderator (Ericsson)
R1-2009710 Summary#3 on Enhancements for URLLC/IIoT on Unlicensed Band Moderator (Ericsson)
From GTW sessions:
Agreements:
· In semi-static channel access mode, a single FFP (periodicity and offset) is associated to an initiating device (gNB or UE) at a given time which can be used for the purpose of channel occupancy. The FFP configuration that is used for initiating channel occupancy purposes, is such that it shall not be changed for at least 200ms
Conclusion:
· For operation on unlicensed channels and irrespective of the adopted LBT mechanism (LBE or FBE), all transmissions in DL and UL are controlled by gNB similarly to licensed channels, and potential collisions or blocking are controlled/mitigated by gNB.
Agreement:
· UE-to-gNB COT sharing in semi-static channel access mode with a gap > 16us is supported
Conclusion:
· If a device X at a given time is initiating a COT, the applicable FFP for the device X is the FFP associated with X.
· If a device X at a given time is sharing a COT initiated by a device Y, the applicable FFP for the device X is the FFP associated with Y.
· Note 1: One of the devices X and Y is a UE and the other is its serving gNB.
· Note 2: Whether or not there is additional restriction on idle period is still FFS.
Agreements:
Down-select one of the following options (target RAN1#104-e):
· Option 1: Both “CG-UCI based procedures” and “CG-DFI based procedures” are enabled or disabled for unlicensed using one RRC parameter i.e. cg-RetransmissionTimer-r16.
· Option 2-a: “CG-UCI based procedures” and “CG-DFI based procedures” are independently enabled or disabled for unlicensed using respective RRC parameter, i.e. new parameter X and cg-RetransmissionTimer-r16, respectively.
· Option 2-b: “CG-UCI based procedures” and “CG-DFI based procedures” are independently enabled or disabled for unlicensed using respective RRC parameter, i.e. new parameter X and new parameter Y, respectively, where X and Y are different from cg-RetransmissionTimer-r16.
· Option 3: CG-UCI based procedures are supported for unlicensed. CG-DFI based procedures are enabled or disabled for unlicensed using one RRC parameter i.e. cg-RetransmissionTimer-r16
· Note: Procedures based on CG-UCI rely on UE including CG-UCI in CG PUSCH at least as in Rel-16 where the values of the respective fields of CG-UCI are decided by UE.
· Note: Procedures based on CG-DFI rely on automatic re-transmission on CG configuration and reception of CG downlink feedback information (DFI) in DCI for re-transmissions.
Decision: As per email decision posted on Nov. 11th,
Agreements:
· The gNB configures a UE to initiate semi-static CO in an unlicensed channel(s) only if the gNB configures the UE also with the higher layer parameters of the gNB’s initiating semi-static CO in the same channel(s).
o Note: UE initiated FBE configuration is configured per serving cell
Decision: As per email decision posted on Nov. 13th,
Agreements:
In semi-static channel access mode, FFP Period for UE-initiated COT is separately provided from FFP period for gNB-initiated COT.
· Note: Any value for the period, shall be at least 1ms and at most 10ms.
· Note: Aim for low complexity operation to handle gNB and UE COT interactions
Agreements:
In semi-static channel access mode, a UE should be able to determine whether a scheduled UL transmission should be transmitted according to shared gNB COT or UE-initiated COT.
· UE determines the initiator of a COT based on at least one of the following alternatives:
o Alt.1: Introduce additional bit field in the scheduling DCI
o Alt.2: Based on ChannelAccess-CPext field in DCI
o Alt.3: Based on a predetermined rule(s)
o Alt.4: Based on RRC signalling
o Alt.5: Based on MAC CE
o FFS other alternatives
· FFS on overriding possibility and/or the assumption
· Note: A scheduled UL transmission cannot be transmitted according to both shared gNB COT and UE-initiated COT.
Agreements:
In semi-static channel access mode:
Final summary in:
R1-2009781 Summary#4 on Enhancements for URLLC/IIoT on Unlicensed Band Moderator (Ericsson)
R1-2009066 Methods for intra-UE multiplexing and prioritization MediaTek Inc.
· Proposal 1: High priority PUCCH resources should be used for the multiplexing
· Proposal 2: Dynamic indication of the multiplexing activation/de-activation is not supported.
· Proposal 3: Guard gap timeline of the new multiplexed PUCCH is of the earliest PUCCH
· Proposal 4: Multiplexing allowed only if the resulted PUCCH is confined within the sub-slot of the HP-PUCCH sub-slot
· Proposal 5: Group-bundling is supported when multiplexing and when the resulted UCI payload is large.
· Proposal 6: Two sets of beta-offset could be defined one for high priority UCI and one for low priority UCI multiplexing
· Proposal 7: beta-offset < 1 could be supported to further protect the HP data when multiplexed with LP-UCI on PUSCH
· Proposal 8: Support simultaneous PUCCH/PUSCH transmissions on different cells for intra-band CA for the same numerology both with aligned and non-aligned channel case.
· Proposal 9: Support simultaneous PUCCH/PUSCH transmissions on different cells for intra-band CA for different numerology if the transmissions are aligned on symbol-level (with the symbol of the lowest SCS as a reference).
o i.e. Allocation on the carrier with higher numerology doesn’t start during an ongoing symbol on the other carrier with the smaller numerology.
· Proposal 10: The UE is to be configured by high-layer parameters to enable or disable simultaneous PUCCH/PUSCH transmission.
· Proposal 11: The UE is to be configured separately for inter-band and intra-band simultaneous PUCCH/PUSCH transmissions.
· Proposal 12: The UE is to be configured for simultaneous PUCCH/PUSCH separately for different priorities on transmissions.
· Proposal 13: Simultaneous PUCCH/PUSCH transmissions is enabled based on specific conditions. E.g. LP-PUCCH carrying HARQ feedback.
· Proposal 14: Support PHY prioritization for the case where high-priority DG-PUSCH collides with low-priority CG-PUSCH
· Proposal 15: The UE is expected to transmit the HP-CG PUSCH and cancel the overlapping LP-DG PUSCH scheduled by the PDCCH starting at latest at the first symbol of the CG PUSCH.
· Proposal 16: The UE is expected to transmit the HP-DG PUSCH and cancel the overlapping LP-CG PUSCH. Further, the UE expects that the first overlapping symbol of the high priority DG is not earlier than Tproc,2+d1 after the last symbol of the PDCCH scheduling the HP-DG PUSCH.
Decision: The document is noted.
R1-2007567 Intra-UE multiplexing enhancements Huawei, HiSilicon
R1-2007658 Intra-UE Multiplexing/Prioritization for Rel-17 URLLC vivo
R1-2007710 Intra-UE Multiplexing/Prioritization Enhancements for IIoT/URLLC Ericsson
R1-2007852 Intra-UE multiplexing and prioritization CATT
R1-2007901 Intra-UE multiplexing prioritization Beijing Xiaomi Software Tech
R1-2008009 Discussion on intra-UE multiplexing/prioritization CMCC
R1-2008060 Discussion on Intra-UE multiplexing/prioritization LG Electronics
R1-2008162 Uplink intra-UE multiplexing and prioritization Samsung
R1-2008282 Enhancements on intra-UE multiplexing/prioritization OPPO
R1-2008358 Considerations in intra-UE UL multiplexing Sony
R1-2008463 Discussion on Intra-UE Multiplexing/Prioritization Apple
R1-2008824 Discussion on enhanced intra-UE multiplexing ZTE
R1-2008843 On UL intra-UE prioritization and multiplexing enhancements Nokia, Nokia Shanghai Bell
R1-2008848 Discussion on Intra-UE prioritization and multiplexing NEC
R1-2008937 Intra-UE multiplexing and prioritization InterDigital, Inc.
R1-2008955 Discussion on Intra-UE multiplexing and prioritization of different priority Panasonic Corporation
R1-2008987 On Intra-UE Multiplexing and Prioritization for Release 17 URLLC/IIoT Intel Corporation
R1-2009013 Intra-UE Multiplexing/Prioritization ETRI
R1-2009104 Intra-UE multiplexing enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2009136 Enhancements on intra-UE UCI multiplexing and PUSCH prioritization Sharp
R1-2009149 Discussion on intra-UE multiplexing/prioritization Spreadtrum Communications
R1-2009185 Discussion on intra-UE multiplexing/prioritization for Rel.17 URLLC NTT DOCOMO, INC.
R1-2009214 Discussion on intra-UE multiplexing ITRI
R1-2009248 Discussion on Intra-UE multiplexing/prioritization for URLLC/IIoT WILUS Inc.
R1-2009260 Intra-UE multiplexing and prioritization for IOT and URLLC Qualcomm Incorporated
R1-2009045 Summary#1 on Intra-UE Multiplexing/Prioritization for R17 OPPO
[103-e-NR-IIoT-URLLC-04] – Jia (OPPO)
Email discussion/approval for intra-UE multiplexing/prioritization
R1-2009546 Summary#1 of email thread [103-e-NR-IIOT_URLLC_enh-04] Moderator (OPPO)
Agreements:
For multiplexing UCIs of different priorities in a PUCCH in R17,
Agreements:
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a PUCCH in R17, when the total number of LP and HP HARQ-ACK bits are more than 2 bits, down-select from the following options in RAN1#104-e:
· Option 1: Support joint coding.
· Option 2: Support separate coding.
· Option 3: Combination of Option1 and 2.
· FFS the details
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a PUCCH in R17, when the total number of LP and HP HARQ-ACK bits is 2 bits, provide design details for decision for the following cases in RAN1#104-e:
· Multiplexing on a PUCCH format 0
· Multiplexing on a PUCCH format 1
Agreements:
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a PUCCH in R17, support a mechanism for gNB to enable/disable the multiplexing.
· FFS the type of the mechanism, e.g. DCI indication and/or RRC configuration
· FFS: Interaction between the enable/disable mechanism and other multiplexing conditions
· FFS for other types of UCI.
Agreements:
For HARQ-ACK multiplexing on PUSCH of different priority in R17, support a mechanism for gNB to enable/disable the multiplexing.
· FFS the type of the mechanism, e.g. DCI indication and/or RRC configuration, beta_offset=0
· FFS: Interaction between the enable/disable mechanism and other multiplexing conditions
· FFS for other types of UCI.
Agreements:
Support PHY prioritization of overlapping high-priority dynamic grant PUSCH and low-priority configured grant PUSCH on a BWP of a serving cell in R17.
· FFS the related cancelation behavior for the PUSCH of lower PHY priority and other details.
o First clarify what is the scope of this feature, e.g. if overlapping between more than 2 channels is considered.
· FFS the timeline requirements.
o First clarify what is the behavior of Rel-16 UE in case of DG/CG/UCI overlapping, with and without uplink skipping enabled.
· FFS UE capability for this feature.
· Note: The main bullet has been agreed in the WID by RAN Plenary.
Including any RAN1 involvement in propagation delay compensation enhancements (including mobility issues, if any).
R1-2008318 Enhancements for support of time synchronization Huawei, HiSilicon
· Proposal 1: RAN1 shall decide for each scenario which value for the TAE should be taken into account.
· Proposal 2: The BS transmit timing error can be the TAE value for evaluation of each scenario.
· Proposal 3: Asymmetry between downlink and uplink channel for smart grid scenario is considered for evaluation, and +/-160ns can be considered.
· Proposal 4: RAN1 shall decide the calculation method for the total error based on all these error component.
Decision: The document is noted.
R1-2007659 Discussion on propagation delay compensation enhancements vivo
R1-2007711 Propagation Delay Compensation Enhancements for Time Synchronization Ericsson
R1-2007853 Discussion on propagation delay compensation enhancements CATT
R1-2008061 Discussion on propagation delay compensation enhancements LG Electronics
R1-2008163 Discussion for propagation delay compensation enhancements Samsung
R1-2008283 Enhancements for Propagation Delay Compensation OPPO
R1-2008464 Discussion on Orphan symbol handling for unlicensed spectrum Apple
R1-2008825 Discussion on propagation delay compensation enhancements ZTE
R1-2008844 Discussion on enhancements for propagation delay compensation Nokia, Nokia Shanghai Bell
R1-2008988 On propagation delay compensation for enhanced timing synchronization Intel Corporation
R1-2009014 Processing time for COT sharing in FBE ETRI
R1-2009261 Enhancements for support of time synchronization for enhanced IIoT and URLLC Qualcomm Incorporated
[103-e-NR-IIoT-URLLC-05] – Chengyan (Huawei )
Email discussion/approval for 8.3.4
R1-2009551 Feature lead summary on propagation delay compensation enhancements (AI 8.3.4) Moderator (Huawei)
Decision: As per email decision posted on Nov. 9th,
Agreements:
Decision: As per email decision posted on Nov. 12th,
Agreement:
· TA adjustment accuracy is not considered for the evaluation of time synchronization error.
Agreements:
For evaluation of the overall time synchronization error for smart grid, companies can take one of the following two options as the assumption for BS transmit timing error:
· Option 1: 200 ns
· Option 2: 65 ns
Please refer to RP-201310 for detailed scope of the WI
Please also refer to RP-202872 for additional guidance for this e-meeting
R1-2101689 Revised Rel-17 NR IIoT/URLLC Work Plan Nokia (Rapporteur)
R1-2100101 Discussion on HARQ-ACK enhancements for eURLLC ZTE
R1-2100181 HARQ-ACK enhancements for Rel-17 URLLC/IIoT OPPO
R1-2100226 UE feedback enhancements for HARQ-ACK Huawei, BUPT, China Southern Power Grid, HiSilicon
R1-2100268 HARQ-ACK Enhancements for IIoT/URLLC Ericsson
R1-2100302 UE feedback enhancements for HARQ-ACK CAICT
R1-2100376 UE feedback enhancements for HARQ-ACK CATT
R1-2100436 HARQ-ACK enahncements for Rel-17 URLLC vivo
R1-2100574 On UE feedback enhancements for HARQ-ACK MediaTek Inc.
R1-2100649 UE HARQ feedback enhancements for URLLC/IIoT Intel Corporation
R1-2100728 HARQ-ACK Feedback Enhancements for URLLC/IIoT Nokia, Nokia Shanghai Bell
R1-2100803 Discussion on physical Layer feedback enhancements Spreadtrum Communications
R1-2100855 Considerations on HARQ-ACK enhancements for URLLC Sony
R1-2100880 Discussion on UE feedback enhancement for HARQ-ACK LG Electronics
R1-2100911 Discussion on UE feedback enhancements for HARQ-ACK China Telecom
R1-2100920 UE feedback enhancements for HARQ-ACK TCL Communication Ltd.
R1-2100948 UE feedback enhancements for HARQ-ACK NEC
R1-2100968 Discussion on UE feedback enhancements for HARQ-ACK Asia Pacific Telecom, FGI
R1-2100993 HARQ-ACK feedback enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2101013 Discussion on UE feedback enhancements for HARQ-ACK Panasonic Corporation
R1-2101039 Discussion on UE feedback enhancements for HARQ-ACK CMCC
R1-2101075 UE feedback enhancements for HARQ-ACK ETRI
R1-2101114 UE feedback enhancement for HARQ-ACK Xiaomi
R1-2101201 On HARQ-ACK reporting enhancements Samsung
R1-2101290 HARQ-ACK enhancements for IIoT and URLLC InterDigital, Inc.
R1-2101378 Views on UE feedback enhancements for HARQ-ACK Apple
R1-2101459 HARQ-ACK enhancement for IOT and URLLC Qualcomm Incorporated
R1-2101539 UE feedback enhancements for HARQ-ACK Sharp
R1-2101612 Discussion on HARQ-ACK feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
R1-2101675 Discussion on HARQ-ACK enhancement for URLLC/IIoT WILUS Inc.
[104-e-NR-R17-IIoT_URLLC-01] – Klaus (Nokia)
Email discussion on UE feedback enhancements for HARQ-ACK
- 1st check point: Jan 28
- 2nd check point: Feb 2
- 3rd check point: Feb 4
R1-2101817 Moderator summary #1 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
From GTW session:
Agreements:
o FFS: Details (including possible conditions for such a deferring, whether or not to consider semi-statically configured flexible symbols for PUCCH availability, etc.)
o Aim for minimal standardization efforts and UE complexity in implementation
Decision: As per email posted on Jan 29th,
Agreements:
Further down-select between the following two options for SPS HARQ-ACK deferral:
· Option 1: Joint RRC configuration of the SPS HARQ-ACK deferral per PUCCH cell group
o Note: any SPS HARQ-ACK within a PUCCH cell group in principle is subject to deferral
· Option 2: The SPS HARQ-ACK deferral is configured per SPS configuration
o Note: part of sps-config, only HARQ-ACK of SPS PDSCH configurations configured for deferral is in principle subject to deferral
From GTW sessions:
Agreements: Support sub-slot based PUCCH repetition for HARQ-ACK based on the Rel-16 PUCCH procedure for slot-based PUCCH applied to sub-slot based PUCCH
· FFS whether or not there is any restriction for the applicability of sub-slot based PUCCH repetition for HARQ-ACK
· Dynamic repetition indication is supported also for sub-slot based PUCCH in Rel-17
o FFS: if the method to be specified in Cov. Enh WI for slot-based PUCCH repetition can be directly applied to sub-slot PUCCH or if changes are needed
Agreements: Support PUCCH repetition for PUCCH formats 0 and 2 at least for sub-slot based PUCCH repetition.
· FFS: Support for slot-based PUCCH repetition
Agreement: Rel-16 UCI multiplexing / PUCCH overriding rules are reused for deferred SPS HARQ-ACK in the target slot, if applicable.
Agreements: For SPS
HARQ-ACK, the deferral from the initial slot/sub-slot determined by k1
in the activation DCI to the target slot/sub-slot determined by k1+
k1def, the UE will check the validity (TBD) of a target slot/sub-slot evaluating from one
slot/sub-slot to the next sub/sub-slot (i.e. in principle k1def
granularity is 1 slot/sub-slot)
Decision: As per email posted on Feb 5th,
Agreement: For SPS HARQ-ACK deferral, for the determination of valid symbols in the initial slot/sub-slot a collision with semi-static DL symbols, SSB and CORESET#0 is regarded as ‘invalid’ or ‘no symbols for UL transmission’.
Agreements: For further study on whether and how to support PUCCH carrier switching in a PUCCH group, focus on the following three alternatives:
· Alt. 1: PUCCH carrier switching is based dynamic indication in DCI
· Alt. 2B: PUCCH carrier switching is based on certain (semi-static) rules
· Alt. 2C: PUCCH carrier switching is based on RRC configured PUCCH cell timing pattern of applicable PUCCH cells
· Note: In above alternatives, it is assumed that HARQ-ACK corresponding to PDSCH received on a Pcell/PScell or an Scell in a PUCCH group, can be sent on a PUCCH on an Scell also instead of only on Pcell/PScell/PUCCH-SCell in the same PUCCH group, as opposed to Rel-16 where HARQ-ACK corresponding to PDSCH received on a Pcell/PScell or an Scell in a PUCCH group can only be sent on Pcell/PScell/PUCCH-SCell in the same PUCCH group.
· Note: Realistic deployment scenarios including TDD configurations should be considered for the study
Final summary in:
R1-2101818 Moderator summary #2 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
R1-2100037 CSI feedback enhancements for URLLC FUTUREWEI
R1-2100102 Discussion on CSI feedback enhancements for eURLLC ZTE
R1-2100182 CSI feedback enhancements for URLLC OPPO
R1-2100227 CSI feedback enhancements Huawei, HiSilicon
R1-2100269 CSI Feedback Enhancements for IIoT/URLLC Ericsson
R1-2100377 CSI feedback enhancements CATT
R1-2100437 CSI feedback enhancements for Rel-17 URLLC vivo
R1-2100575 CSI feedback enhancements for URLLC MediaTek Inc.
R1-2100650 CSI feedback enhancements for URLLC/IIoT Intel Corporation
R1-2100790 Discussion on CSI feedback enhancements Spreadtrum Communications
R1-2100830 CSI feedback enhancements InterDigital, Inc.
R1-2100835 CSI feedback enhancements for URLLC/IIoT use cases Nokia, Nokia Shanghai Bell
R1-2100856 Considerations on CSI feedback enhancements Sony
R1-2100881 Discussion on CSI feedback enhancements for URLLC LG Electronics
R1-2100994 CSI feedback enhancements for IIoT/URLLC Lenovo, Motorola Mobility
R1-2101014 Discussion on CSI feedback enhancements Panasonic Corporation
R1-2101040 Discussion on CSI feedback enhancements for URLLC CMCC
R1-2101202 Improving MCS Selection for URLLC Samsung
R1-2101379 Views on CSI feedback enhancements Apple
R1-2101460 CSI enhancement for IOT and URLLC Qualcomm Incorporated
R1-2101613 Discussion on CSI feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
[104-e-NR-R17-IIoT_URLLC-02] – Paul (InterDigital)
Email discussion on CSI feedback enhancements
- 1st check point: Jan 28
- 2nd check point: Feb 2
- 3rd check point: Feb 4
R1-2101811 Feature lead summary #1 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
R1-2101879 Feature lead summary #2 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
R1-2101961 Feature lead summary #3 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
R1-2102131 Feature lead summary #4 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
Conclusion: Continue evaluation of new reporting Case 1 and Case 2 for the schemes identified in Appendix B of R1-2102131.
· Companies are encouraged to provide their views on each scheme against each criterion in respective Tables in Appendix B.
· Companies are encouraged to provide additional evaluation results for as many schemes as possible, based on assumptions agreed in RAN1#102-e.
· Aim for down-selection at RAN1#104-b-e by taking into account evaluation results and assessment against criteria from Appendix B.
R1-2100054 Further considerations on UE initiated COT for FFP FUTUREWEI
R1-2100103 Discussion on unlicensed band URLLC/IIoT ZTE
R1-2100183 Enhancements for unlicensed band URLLC/IIoT OPPO
R1-2100229 Uplink enhancements for URLLC in unlicensed controlled environments Huawei, BUPT, China Southern Power Grid, HiSilicon
R1-2100270 Enhancements for IIoT/URLLC on Unlicensed Band Ericsson
R1-2100378 Enhancements for unlicensed band URLLC/IIoT CATT
R1-2100438 Enhancements for unlicensed band URLLC/IIoT vivo
R1-2100543 Enhancements for unlicensed band URLLC/IIoT TCL Communication Ltd.
R1-2100576 On the enhancements for unlicensed band URLLC/IIoT MediaTek Inc.
R1-2100626 UL enhancements for IIoT/URLLC in unlicensed controlled environment Nokia, Nokia Shanghai Bell
R1-2100651 Discussion on enhancements to URLLC/IIoT in unlicensed band Intel Corporation
R1-2100691 Enhancements for unlicensed band URLLC/IIoT NEC
R1-2100791 Discussion on enhancements for unlicensed band URLLC/IIoT Spreadtrum Communications
R1-2100857 Considerations on unlicensed URLLC Sony
R1-2100882 Discussion on unlicensed band URLLC/IIOT LG Electronics
R1-2100995 Enhancements for unlicensed band IIoT/URLLC Lenovo, Motorola Mobility
R1-2101015 Enhancements for unlicensed band URLLC/IIoT Panasonic Corporation
R1-2101076 Enhancements for unlicensed band URLLC/IIoT ETRI
R1-2101115 Enhancement for unlicensed band URLLC/IIoT Xiaomi
R1-2101203 Enhancements for unlicensed band URLLC/IIoT Samsung
R1-2101291 Enhancements for unlicensed band URLLC/IIoT InterDigital, Inc.
R1-2101333 Unlicensed spectrum operation for URLLC/IIoT Charter Communications
R1-2101380 URLLC uplink enhancements for unlicensed spectrum Apple
R1-2101461 Uplink enhancements for URLLC in unlicensed controlled environments Qualcomm Incorporated
R1-2101540 Enhancements for unlicensed band URLLC/IIoT Sharp
R1-2101614 Discussion on enhancements for unlicensed band URLLC NTT DOCOMO, INC.
R1-2101676 Discussion on enhancement for unlicensed URLLC/IIoT WILUS Inc.
[104-e-NR-R17-IIoT_URLLC-03] – Sorour (Ericsson)
Email discussion on enhancements for unlicensed band URLLC/IIoT
- 1st check point: Jan 28
- 2nd check point: Feb 2
- 3rd check point: Feb 4
R1-2101830 Summary#1 - URLLC/IIoT operation on Unlicensed Band Moderator (Ericsson)
R1-2101902 Summary#2 - URLLC/IIoT operation on Unlicensed Band Moderator (Ericsson)
From GTW session on Jan 27th,
Agreement:
Agreement:
R1-2101955 Summary#3 - URLLC/IIoT operation on Unlicensed Band Moderator (Ericsson)
R1-2102064 Summary#4 - URLLC/IIoT operation on Unlicensed Band Moderator (Ericsson)
From GTW session on Feb 2nd,
Agreement:
· In semi-static channel access mode:
o An FFP period for UE-initiated COT is configured as the same, integer multiple of, or inter-factor of the FFP period configured for gNB-initiated COT
o FFP period for UE-initiated COT can be configured independently from FFP period of gNB-initiated COT, if the UE indicates the corresponding capability
o FFP offset for UE-initiated COT is the starting point of first UE FFP relative to the radio frame X boundary.
§ The offset value range is 0 ≤ offset ＜FFP period of UE-initiated COT
· FFS on X (e.g. X=0, or X= even index number)
Agreement:
In semi-static channel access mode when a UE can operate as initiating device,
· Alt-a: Determination based on the content in the scheduling DCI
· FFS on whether the corresponding field(s) can be absent in DCI
§ If absent, determination based on the rules applied for configured UL transmissions is applied
· FFS whether/how to handle the case when the gNB schedules an UL transmission in the next gNB’s FFP period
· Alt-b: Determination based on the rules applied for a configured UL transmission
R1-2102173 Summary#5 - URLLC/IIoT operation on Unlicensed Band Moderator (Ericsson)
From GTW session on Feb 4th,
Agreement:
In semi-static channel access mode when a UE can operate as UE-initiated COT,
Agreement:
· In semi-static channel access mode, sharing a UE initiated COT through the gNB to other intra-cell UEs for UL transmissions, is not supported.
Final summary in:
R1-2102175 Summary#6 - URLLC/IIoT operation on Unlicensed Band Moderator (Ericsson)
R1-2100104 Discussion on enhanced intra-UE multiplexing ZTE
R1-2100184 Enhancements on intra-UE multiplexing/prioritization OPPO
R1-2100228 Intra-UE multiplexing enhancements Huawei, BUPT, China Southern Power Grid, HiSilicon
R1-2100271 Intra-UE Multiplexing/Prioritization Enhancements for IIoT/URLLC Ericsson
R1-2100303 Considerations of intra UE multiplexing CAICT
R1-2100379 Intra-UE multiplexing and prioritization CATT
R1-2100439 Intra-UE Multiplexing/Prioritization for Rel-17 URLLC vivo
R1-2100577 Methods for intra-UE multiplexing and prioritization MediaTek Inc.
R1-2100652 Considerations on intra-UE multiplexing and prioritization Intel Corporation
R1-2100692 Discussion on Intra-UE prioritization and multiplexing NEC
R1-2100729 On UL intra-UE prioritization and multiplexing enhancements Nokia, Nokia Shanghai Bell
R1-2100804 Discussion on intra-UE multiplexing/prioritization Spreadtrum Communications
R1-2100831 Intra-UE Multiplexing/Prioritization InterDigital, Inc.
R1-2100858 Considerations on intra-UE UL multiplexing Sony
R1-2100883 Discussion on Intra-UE multiplexing/prioritization LG Electronics
R1-2100921 Intra-UE Multiplexing and Prioritization TCL Communication Ltd.
R1-2100970 Discussion on Intra-UE multiplexing/prioritization Asia Pacific Telecom, FGI
R1-2100996 Intra-UE multiplexing enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2101016 Discussion on Intra-UE multiplexing and prioritization of different priority Panasonic Corporation
R1-2101041 Discussion on intra-UE multiplexing or prioritization CMCC
R1-2101077 Intra-UE Multiplexing/Prioritization ETRI
R1-2101116 Intra-UE multiplexing prioritization for URLLC/IIoT Xiaomi
R1-2101204 Uplink intra-UE multiplexing and prioritization Samsung
R1-2101381 Views on Intra-UE Multiplexing/Prioritization Apple
R1-2101462 Intra-UE multiplexing and prioritization for IOT and URLLC Qualcomm Incorporated
R1-2101541 Enhancements on intra-UE UCI multiplexing and PUSCH prioritization Sharp
R1-2101570 Discussion on intra-UE multiplexing ITRI
R1-2101615 Discussion on intra-UE multiplexing/prioritization for Rel.17 URLLC NTT DOCOMO, INC.
R1-2101677 Discussion on intra-UE multiplexing/prioritization for URLLC/IIoT WILUS Inc.
[104-e-NR-R17-IIoT_URLLC-04] – Jia (OPPO)
Email discussion on intra-UE multiplexing/prioritization
- 1st check point: Jan 28
- 2nd check point: Feb 2
- 3rd check point: Feb 4
R1-2101842 Summary#1 of email thread [104-e-NR-R17-IIoT_URLLC-04] Moderator (OPPO)
From GTW sessions:
Agreements:
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a PUCCH in R17,
· Use a PUCCH resource in the second PUCCH-Config (the PUCCH-config containing the PUCCH resource of the HP HARQ-ACK) at least in case the total number of LP and HP HARQ-ACK bits is more than 2.
· FFS: The PUCCH resource is configured dedicated for multiplexing of HP HARQ-ACK and LP HARQ-ACK.
· FFS in case the total number of LP and HP HARQ-ACK bits is 2.
· FFS details
Working assumption:
Reuse Rel-15 intra-UE PUCCH/PUSCH multiplexing timeline requirements for Rel-17 intra-UE PUCCH/PUSCH multiplexing with different priorities
· FFS whether or not to specify a different behavior than Rel-15 when the timeline requirements are not met
Agreements:
For multiplexing LP HARQ-ACK in a HP PUSCH, support 0< beta-offset <1.
· FFS value(s)
· FFS to additionally support beta-offset =0 or a value disabling the multiplexing
· Aim to NOT increase the corresponding bitwidth in the DCI (compared to Rel-16)
Agreements:
Per UE with the capability of inter-band CA, simultaneous PUCCH/PUSCH transmission of different PHY priorities over different cells can be RRC configured within the same PUCCH group
Decision: As per email posted on Feb 5th,
Agreements:
When a PUCCH carrying HP SR with PF0 overlaps with a PUCCH carrying LP HARQ-ACK with PF0, further study the following options (proponents are encouraged to provide more details and analysis):
· Opt.1: The positive SR and HARQ-ACK are multiplexed and transmitted on the SR resource.
o Opt.1a: The UE does not transmit negative SR.
o Opt.1b: For negative SR, the UE transmit only HARQ-ACK on the HARQ-ACK resource.
o Opt.1c: For negative SR, the UE transmits SR and HARQ-ACK on the SR resource
o FFS: whether with power boost to transmit multiplexed payload or not.
· Opt.2: The SR and HARQ-ACK are multiplexed and transmitted on the HARQ-ACK resource.
o Opt.2a: If SR is positive, an offset (e.g. 1 PRB) is added to the starting PRB of the HARQ-ACK PUCCH resource.
o Opt.2b: Using 4 CS values as for SR+1-bit HARQ-ACK in Rel-15/16. For the case of 2-bit HARQ-ACK, the HARQ-ACK is reduced/compressed to 1-bit.
o Opt.2c: If SR is positive, SR is multiplexed on HARQ-ACK resource in the same way as Rel-15. If SR is negative, transmit only HARQ-ACK on HARQ-ACK resource.
· Opt.3: No enhancement over Rel-16.
· Other options not excluded.
· FFS: Whether/How to differentiate HP SR and LP SR when multiplexed with LP HARQ-ACK?
Agreements:
When a PUCCH carrying HP SR with PF0 overlaps with a PUCCH carrying LP HARQ-ACK with PF1, further study the following options (proponents are encouraged to provide more details and analysis):
· Opt.1: The positive SR and HARQ-ACK are multiplexed and transmitted on the SR resource.
o Opt.1a: The UE does not transmit negative SR.
o Opt.1b: For negative SR, the UE transmit only HARQ-ACK on the HARQ-ACK resource.
o Opt.1c: For negative SR, the UE transmits SR and HARQ-ACK on the SR resource
o FFS: whether with power boost to transmit multiplexed payload or not.
· Opt.2: The SR and HARQ-ACK are multiplexed and transmitted on the HARQ-ACK resource.
o Opt.2a: If SR is positive, an offset (e.g. 1 PRB) is added to the starting PRB of the HARQ-ACK PUCCH resource.
o Opt.2b: Applying QPSK for SR+1-bit HARQ-ACK. For the case of 2-bit HARQ-ACK, the HARQ-ACK is reduced/compressed to 1-bit.
o FFS on conditions of multiplexing.
· Opt.3: For positive SR, transmit HARQ-ACK on the SR resource. For negative SR, transmit HARQ-ACK on the HARQ-ACK resource.
· Opt.4: For positive SR, transmit SR on the SR resource and drop HARQ-ACK. For negative SR, transmit HARQ-ACK on the HARQ-ACK resource.
· Opt.5: No enhancement over Rel-16.
· Other options not excluded.
· FFS: Whether/How to differentiate HP SR and LP SR when multiplexed with LP HARQ-ACK?
Agreements:
When a PUCCH carrying HP SR with PF1 overlaps with a PUCCH carrying LP HARQ-ACK with PF0, further study the following options (proponents are encouraged to provide more details and analysis):
· Opt.1: The SR and HARQ-ACK are multiplexed and transmitted on the SR resource.
o Opt.1a: For positive SR, the UE transmits the PUCCH in the resource using PUCCH format 1 for SR. The value of cyclic shift of sequence, i.e., , of this PUCCH format 1 is determined by HARQ-ACK, and the bit, i.e., b(0), of this PUCCH format 1 is determined by SR. For negative SR, the UE transmits only a PUCCH with HARQ-ACK information and drops the PUCCH with negative SR.
o Opt.1b: SR and HARQ-ACK are multiplexed and modulated to be transmitted on the SR resource
· Opt.2: The SR and HARQ-ACK are multiplexed and transmitted on the HARQ-ACK resource.
o Opt.2a: If SR is positive, an offset (e.g. 1 PRB) is added to the starting PRB of the HARQ-ACK PUCCH resource.
o Opt.2b: Using 4 CS values as for SR+1-bit HARQ-ACK in Rel-15/16. For the case of 2-bit HARQ-ACK, the HARQ-ACK is reduced/compressed to 1-bit.
o Opt.2c: If SR is positive, SR is multiplexed on HARQ-ACK resource in the same way as Rel-15. If SR is negative, transmit only HARQ-ACK on HARQ-ACK resource.
o Opt.2d: HP SR and LP HARQ-ACK are multiplexed by the Rel-15 cyclic shift only if latency requirement for HP SR is met. Otherwise, drop the LP HARQ-ACK and only transmit the HP SR on its resource.
· Opt.3: For positive SR, transmit HARQ-ACK on the SR resource. For negative SR, transmit HARQ-ACK on the HARQ-ACK resource.
· Opt.4: No enhancement over Rel-16.
· Other options not excluded.
· FFS: Whether/How to differentiate HP SR and LP SR when multiplexed with LP HARQ-ACK?
Including any RAN1 involvement in propagation delay compensation enhancements (including mobility issues, if any).
R1-2100105 Discussion on propagation delay compensation enhancements ZTE
R1-2100185 Enhancements for Propagation Delay Compensation OPPO
R1-2100272 Propagation Delay Compensation Enhancements for Time Synchronization Ericsson
R1-2100380 Discussion on propagation delay compensation enhancements CATT
R1-2100440 Discussion on propagation delay compensation enhancements vivo
R1-2100578 Discussion on propagation delay compensation for time synchronization MediaTek Inc.
R1-2100653 Propagation delay compensation analysis and design considerations Intel Corporation
R1-2100730 Discussion on enhancements for propagation delay compensation Nokia, Nokia Shanghai Bell
R1-2100884 Discussion on propagation delay compensation enhancements LG Electronics
R1-2101078 Propagation delay compensation enhancements ETRI
R1-2101205 Discussion for propagation delay compensation enhancements Samsung
R1-2101265 Enhancements for support of time synchronization Huawei, BUPT, China Southern Power Grid, HiSilicon
R1-2101382 Orphan symbol treatment in unlicensed spectrum access Apple
R1-2101463 Enhancements for support of time synchronization for enhanced IIoT and URLLC Qualcomm Incorporated
[104-e-NR-R17-IIoT_URLLC-05] – Chengyan (Huawei)
Email discussion on propagation delay compensation enhancements
- 1st check point: Jan 28
- 2nd check point: Feb 2
- 3rd check point: Feb 4
R1-2101816 Feature lead summary on propagation delay compensation enhancements Moderator (Huawei)
Agreements: Take ±100 ns as the assumption for downlink frame timing detection error (errorUE,DL,RX) at the UE for evaluation of the overall time synchronization error for TA based propagation delay compensation, if downlink frame timing detection error needs to be considered separately.
R1-2102224 Draft LS on UE transmit timing error Huawei
Decision: As per email posted on feb 5th, the draft LS is endorsed. Final LS is approved in R1-2102245.
Final summary in:
R1-2101896 Feature lead summary#2 on propagation delay compensation enhancements Moderator (Huawei)
Please refer to RP-210854 for detailed scope of the WI
Please also refer to RP-202872 for additional guidance for this e-meeting
R1-2102825 Moderator summary #1 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
R1-2102351 UE feedback enhancements for HARQ-ACK Huawei, China Southern Power Grid, BUPT, HiSilicon
R1-2102392 HARQ-ACK enhancements for Rel-17 URLLC/IIoT OPPO
R1-2102454 Discussion on HARQ-ACK enhancements for Rel-17 URLLC Spreadtrum Communications
R1-2102493 Discussion on HARQ-ACK enhancements for eURLLC ZTE
R1-2102521 HARQ-ACK enahncements for Rel-17 URLLC vivo
R1-2102571 UE feedback enhancements for HARQ-ACK CAICT
R1-2102628 UE feedback enhancements for HARQ-ACK CATT
R1-2102694 On UE feedback enhancements for HARQ-ACK MediaTek Inc.
R1-2102729 Discussion on UE feedback enhancements for HARQ-ACK Asia Pacific Telecom, FGI
R1-2102744 HARQ-ACK Enhancements for IIoT/URLLC Ericsson
R1-2102819 HARQ-ACK Feedback Enhancements for URLLC/IIoT Nokia, Nokia Shanghai Bell
R1-2102867 Discussion on UE feedback enhancements for HARQ-ACK China Telecom
R1-2102910 Discussion on UE feedback enhancements for HARQ-ACK CMCC
R1-2102922 UE feedback enhancement for HARQ-ACK TCL Communication Ltd.
R1-2102982 UE feedback enhancement for HARQ-ACK Xiaomi
R1-2103027 Further details on UE HARQ feedback enhancements Intel Corporation
R1-2103103 Views on URLLC HARQ feedback enhancements Apple
R1-2103163 HARQ-ACK enhancement for IOT and URLLC Qualcomm Incorporated
R1-2103200 HARQ-ACK enhancements for IIoT and URLLC InterDigital, Inc.
R1-2103205 Discussion on UE feedback enhancements for HARQ-ACK Panasonic Corporation
R1-2103236 On HARQ-ACK reporting enhancements Samsung
R1-2103300 Considerations on HARQ-ACK enhancements for URLLC Sony
R1-2103325 UE feedback enhancements for HARQ-ACK ETRI
R1-2103347 Discussion on UE feedback enhancement for HARQ-ACK LG Electronics
R1-2103473 UE feedback enhancements for HARQ-ACK Sharp
R1-2103527 UE feedback enhancements for HARQ-ACK NEC
R1-2103574 Discussion on HARQ-ACK feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
R1-2103610 HARQ-ACK feedback enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2103695 Discussion on HARQ-ACK enhancement for URLLC/IIoT WILUS Inc.
//Handled under NWM – See RAN1-104b-e-NWM-NR-R17- IIoT_URLLC-01 as the document name
[104b-e-NR-R17-IIoT_URLLC-01] – Klaus (Nokia)
Email discussion on UE feedback enhancements for HARQ-ACK
- 1st check point: 4/15
- 2nd check point: 4/19
- 3rd check point: 4/20
R1-2103882 Moderator summary #2 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
Agreement: For SPS HARQ-ACK deferral, for the determination of valid symbols in the target slot/sub-slot a collision with semi-static DL symbols, SSB and CORESET#0 is regarded as ‘invalid’ or ‘no symbols for UL transmission’.
Agreements: For SPS HARQ-ACK deferral, support a limit on the maximum deferral of SPS HARQ in terms of k1def or k1+ k1def
· FFS: limitation given by a maximum value of k1def or a maximum of k1eff =k1+ k1def
· FFS how the limitation is determined (e.g. by K1 set(s) or RRC configured limit)
Agreements: For SPS HARQ-ACK deferral, there is no lower limit defined for k1def
Conclusion:
No support for dynamic indication of skipped SPS PDSCH occasions in Rel-17 as part of this WI.
R1-2103883 Moderator summary #3 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
R1-2104038 Moderator summary #4 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
Agreement: Restrict the further discussions on the initial slot handling for SPS HARQ-ACK deferral to the identified alternatives Alt. 1, Alt. 1A and 2.
Agreement: For SPS HARQ-ACK deferral, the limit on the maximum deferral of SPS HARQ is defined in terms of k1eff =k1+ k1def.
Working assumption: To handle the collision for the same HARQ process due to deferred SPS HARQ-ACK the following behaviour is to be specified:
· In case the UE receives PDSCH of a certain HARQ Process ID, the deferred SPS HARQ bit(s) for this HARQ Process ID are dropped.
Agreement: For SPS HARQ-ACK deferral, the initial HARQ-ACK transmission occasion is considered to determine the out-of-order HARQ condition
Agreement: Support Type-1 HARQ-ACK codebook for sub-slot based PUCCH configuration in Rel-17.
· The properties of the Type-1 HARQ-ACK codebook for sub-slot PUCCH at least includes that a PDSCH TDRA is associated with a UL /PUCCH sub-slot if the end of the PDSCH overlaps with the associated sub-slot determined by a k1 in the set of sub-slot timing values K1.
· FFS: whether the PDSCH TDRA grouping is performed per DL slot or sub-slot
o Decide between PDSCH TDRA grouping per DL slot and sub-slot during RAN1#105-e
Final summary in R1-2104039.
R1-2102352 CSI feedback enhancements Huawei, HiSilicon, SIA
R1-2102393 CSI feedback enhancements for URLLC OPPO
R1-2102455 Discussion on CSI feedback enhancements Spreadtrum Communications
R1-2102494 Discussion on CSI feedback enhancements for eURLLC ZTE
R1-2102522 CSI feedback enhancements for Rel-17 URLLC vivo
· Proposal 1: For new CSI report triggering for A-CSI, A-CSI triggered by DL grant is preferred.
· Proposal 2: For A-CSI triggered by DL grant where CSI and HARQ-ACK are multiplexed on the same PUCCH resource, CSI computation time needs to be reduced, e.g align with PDSCH processing time N1.
· Proposal 3: For A-CSI triggered by DL grant where CSI and HARQ-ACK are transmitted on separate resource, A-CSI transmitted on a separate PUCCH resource or PUSCH resource can be considered.
· Proposal 4: Support Case 1 New reporting quantity with CQI update only, where the latest RI/PMI based on the previous CSI measurement for RI/PMI can be assumed.
· Proposal 5: Full sub-band 4-bit CQI reporting is preferred for Rel-17 CSI enhancement.
· Proposal 6: If overhead reduction is needed for URLLC CSI enhancement, how to reduce the CSI computation complexity and the overhead for CSI report based on the existing CSI measurement/reporting mechanisms should be prioritized.
Decision: The document is noted.
R1-2102629 CSI feedback enhancements CATT
R1-2102695 CSI feedback enhancements for URLLC MediaTek Inc.
R1-2102739 CSI feedback enhancements InterDigital, Inc.
R1-2102745 CSI Feedback Enhancements for IIoT/URLLC Ericsson
R1-2102759 CSI feedback enhancements for URLLC FUTUREWEI
R1-2102872 Discussion on CSI Feedback Enhancements Quectel, Langbo
R1-2102911 Discussion on CSI feedback enhancements for URLLC CMCC
R1-2103028 Analysis of enhanced CSI feedback schemes Intel Corporation
R1-2103104 Views on URLLC CSI feedback enhancements Apple
R1-2103800 CSI enhancement for IOT and URLLC Qualcomm Incorporated (rev of R1-2103164)
R1-2103237 On Enahncements of CSI Reports for URLLC Samsung
R1-2103301 Considerations on CSI feedback enhancements Sony
R1-2103348 Discussion on CSI feedback enhancements for URLLC LG Electronics
R1-2103434 CSI feedback enhancements for URLLC/IIoT use cases Nokia, Nokia Shanghai Bell
R1-2103575 Discussion on CSI feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
R1-2103611 CSI feedback enhancements for URLLC/IIoT Lenovo, Motorola Mobility
R1-2102749 Summary of additional discussions on CSI feedback enhancements for enhanced URLLC/IIoT after RAN1#104-e Moderator (InterDigital, Inc.)
[104b-e-NR-R17-IIoT_URLLC-02] – Paul (InterDigital)
Email discussion on CSI feedback enhancements
- 1st check point: 4/15
- 2nd check point: 4/19
- 3rd check point: 4/20
R1-2103786 Feature lead summary #1 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
Conclusion:
For new reporting Case 1, do not consider further the following schemes:
· Case 1-2: CSI prediction
· Case 1-4: Interference covariance matrix
· Case 1-9: Reference wideband CQI excludes worst sub-bands
· Case 1-10: CSI expiration time
R1-2103787 Feature lead summary #2 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
R1-2103955 Feature lead summary #3 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
Agreements:
For new reporting Case 2, focus study on reporting of delta-CQI/MCS (Case 2-3):
· Note: this delta-CQI/MCS is determined based on UE implementation (for example, using SINR, LLR, raw BER, flipped bits, LDPC iterations, BLEP, # fail parity checks, etc.)
o Companies are encouraged to provide more details in their analysis
· FFS: Granularity of new report type (e.g. units of CQI or MCS, how many bits)
· FFS: Whether quantity reported is relative to the scheduled MCS
Agreement: Focus study on the following for new reporting Case 1:
· Reporting of new metric, where new metric shall be determined based on network configured channel and interference measurement interval (multiple CMR and/or IMR instances) to enable accurate MCS selection.
o Downselect by RAN1#105 to at most a single method from the following options:
§ Mean-CQI/SINR and stdev-CQI/SINR (FFS details)
§ CSI based on worst IMR occasion (FFS details)
§ Interference standard deviation (FFS details)
§ Worst-M CQI (FFS details)
o FFS: Whether network configured channel and interference measurement interval can also be applied to existing CSI type
· Increasing granularity of subband CQI (e.g. 3-bits differential subband CQI or 4-bits full subband CQI).
· Updating only CQI in a report, where CQI is conditioned on a previous instance in which RI/PMI/(CRI) is updated.
o Applicable for same reporting quantity as R16 for CQI.
o FFS: Whether network configured channel and interference measurement interval can also be applied
o FFS: Whether RI/PMI/(CRI) is transmitted in a report where only CQI is updated
o
FFS:
how to report the updated CQI
o
FFS: whether the CQI
processing time can be is reduced compared to Rel-16 CSI processing
delay
Final summary in R1-2103956.
R1-2102354 Uplink enhancements for URLLC in unlicensed controlled environments Huawei, China Southern Power Grid, BUPT, HiSilicon
R1-2102394 Enhancements for unlicensed band URLLC/IIoT OPPO
R1-2102456 Discussion on enhancements for unlicensed band URLLC/IIoT Spreadtrum Communications
R1-2102495 Discussion on unlicensed band URLLC/IIoT ZTE
R1-2102523 Enhancements for unlicensed band URLLC/IIoT vivo
R1-2102630 Enhancements for unlicensed band URLLC/IIoT CATT
R1-2102648 UL enhancements for IIoT/URLLC in unlicensed controlled environment Nokia, Nokia Shanghai Bell
R1-2102696 On the enhancements for unlicensed band URLLC/IIoT MediaTek Inc.
R1-2102730 Enhancements for unlicensed band URLLC/IIoT Asia Pacific Telecom, FGI
R1-2102746 Enhancements for IIoT/URLLC on Unlicensed Band Ericsson
R1-2102760 Further considerations on UE initiated COT for FFP FUTUREWEI
R1-2102813 Enhancements for unlicensed band URLLC/IIoT NEC
R1-2102983 Enhancement for unlicensed band URLLC/IIoT Xiaomi
R1-2103029 Further Details on Enabling URLLC/IIoT in Unlicensed Band Intel Corporation
R1-2103105 URLLC uplink enhancements for unlicensed spectrum Apple
R1-2103165 Uplink enhancements for URLLC in unlicensed controlled environments Qualcomm Incorporated
R1-2103201 Enhancements for unlicensed band URLLC/IIoT InterDigital, Inc.
R1-2103206 Enhancements for unlicensed band URLLC/IIoT Panasonic Corporation
R1-2103238 Enhancements for unlicensed band URLLC/IIoT Samsung
R1-2103302 Considerations on unlicensed URLLC Sony
R1-2103326 Enhancements for unlicensed band URLLC/IIoT ETRI
R1-2103349 Discussion on unlicensed band URLLC/IIOT LG Electronics
R1-2103474 Enhancements for unlicensed band URLLC/IIoT Sharp
R1-2103576 Discussion on enhancements for unlicensed band URLLC NTT DOCOMO, INC.
R1-2103612 Enhancements for unlicensed band URLLC/IIoT Lenovo, Motorola Mobility
R1-2103696 Discussion on enhancement for unlicensed URLLC/IIoT WILUS Inc.
R1-2103728 Unlicensed spectrum operation for URLLC/IIoT Charter Communications
[104b-e-NR-R17-IIoT_URLLC-03] – Sorour (Ericsson)
Email discussion on enhancements for unlicensed band URLLC/IIoT
- 1st check point: 4/15
- 2nd check point: 4/19
- 3rd check point: 4/20
R1-2103849 Summary#1 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
R1-2103850 Summary#2 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
Agreement:
· Support explicit RRC configuration for the UE-FFP parameters including period and offset in RRC connected mode.
Agreements:
· For semi-static channel access mode, the offset value for configuration of a UE-FFP for a serving cell has a symbol level granularity.
R1-2103851 Summary#3 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
R1-2103852 Summary#4 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
Agreement:
· For semi-static channel access mode, in addition to the agreed set of period values for configuration of a UE-FFP for a serving cell:
o Do not support any additional period value
Agreement:
· For semi-static channel access mode, the starting point of first UE FFP for a serving cell
o is relative to the boundary of the radio frame of even index number (i.e. X=even indexed number in RAN1#104-e agreement).
Agreement:
· In semi-static channel access mode, the gNB can schedule by a DCI UL transmission(s) in a later g-FFP that is different from the g-FFP that carries the scheduling DCI.
o The UL transmission can occur only if the corresponding channel access requirements are met.
§ FFS on details.
Agreement:
· In semi-static channel access mode, the gNB can schedule by a DCI DL transmission(s) in a later g-FFP that is different from the g-FFP that carries the scheduling DCI.
o The DL transmission can occur only if the corresponding channel access requirements are met.
§ FFS on details.
Agreement:
· Select one of the following options (aiming for RAN1#105-e):
o
Option 1: Do not support
PUSCH repetition Type Bwhen using based on NR-U Rel-16 based
CG for unlicensed band operation.
o
Option 2: Support enhancements of PUSCH
repetition Type B when using based on NR-U
Rel-16based CG for unlicensed band operation. FFS
whether/how to enhance
Agreements
· For PUSCH repetition Type B enhancements on unlicensed spectrum, further study whether PUSCH segmentation should take into account the idle period of an FFP.
o FFS on details
Agreements
· For PUSCH repetition Type B enhancements on unlicensed spectrum, further study whether orphan symbol(s) are transmitted if they are between two actual repetitions that are transmitted. FFS on details
Conclusion:
· In semi-static channel access mode, a UE as an initiating device, is allowed to transmit during the idle period of any FFP associated with the serving gNB if the UE transmission is based on UE initiated COT
o Note: the gNB may disallow UL transmission during symbols of the idle period by configuring them either as semi-static DL symbols, or indicating them as DL with SFI.
Agreement:
· Option 2-b and option 3 are not considered further for the agreement in RAN1#103-e regarding CG harmonization
Final summary in R1-2103960.
R1-2102353 Intra-UE multiplexing enhancements Huawei, China Southern Power Grid, BUPT, HiSilicon
R1-2102395 Enhancements on intra-UE multiplexing/prioritization OPPO
R1-2102457 Discussion on intra-UE multiplexing/prioritization Spreadtrum Communications
R1-2102496 Discussion on enhanced intra-UE multiplexing ZTE
R1-2102524 Intra-UE Multiplexing/Prioritization for Rel-17 URLLC vivo
R1-2102631 Intra-UE multiplexing and prioritization CATT
R1-2102697 Methods for intra-UE multiplexing and prioritization MediaTek Inc.
R1-2102731 Discussion on Intra-UE multiplexing/prioritization Asia Pacific Telecom, FGI
R1-2102740 Intra-UE multiplexing and prioritization InterDigital, Inc.
R1-2102747 Intra-UE Multiplexing/Prioritization Enhancements for IIoT/URLLC Ericsson
R1-2102814 Discussion on Intra-UE prioritization and multiplexing NEC
R1-2102820 On UL intra-UE prioritization and multiplexing enhancements Nokia, Nokia Shanghai Bell
R1-2102868 Discussion on intra-UE multiplexing and prioritization China Telecom
R1-2102871 Discussion on Intra-UE Multiplexing/Prioritization Quectel, Langbo
R1-2102912 Discussion on intra-UE multiplexing or prioritization CMCC
R1-2102952 Intra-UE Multiplexing and Prioritization TCL Communication Ltd.
R1-2102984 Intra-UE multiplexing prioritization for URLLC/IIoT Xiaomi
R1-2103030 Further analysis and details of intra-UE multiplexing and prioritization Intel Corporation
R1-2103106 Views on intra-UE multiplexing/prioritization Apple
R1-2103166 Intra-UE multiplexing and prioritization for IOT and URLLC Qualcomm Incorporated
R1-2103207 Discussion on Intra-UE multiplexing and prioritization of different priority Panasonic Corporation
R1-2103239 Uplink intra-UE multiplexing and prioritization Samsung
R1-2103303 Considerations on intra-UE UL multiplexing Sony
R1-2103327 Intra-UE Multiplexing/Prioritization ETRI
R1-2103350 Discussion on Intra-UE multiplexing/prioritization LG Electronics
R1-2103475 Enhancements on intra-UE UCI multiplexing with different priorities and channel prioritization Sharp
R1-2103577 Discussion on intra-UE multiplexing/prioritization for Rel.17 URLLC NTT DOCOMO, INC.
R1-2103613 Intra-UE multiplexing enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2103632 Discussion on intra-UE multiplexing ITRI
R1-2103697 Discussion on intra-UE multiplexing/prioritization for URLLC/IIoT WILUS Inc.
R1-2103857 Summary#1 of R17 intra-UE Multiplexing/Prioritization Moderator (OPPO)
[104b-e-NR-R17-IIoT_URLLC-04] – Jia (OPPO)
Email discussion on intra-UE multiplexing/prioritization
- 1st check point: 4/15
- 2nd check point: 4/19
- 3rd check point: 4/20
R1-2103868 Summary#1 of email thread [104b-e-NR-R17-IIoT_URLLC-04] Moderator (OPPO)
Agreements:
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a PUCCH in R17, when the total number of LP and HP HARQ-ACK bits is more than 2, support separate coding for the two HARQ-ACKs.
Agreement:
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a PUSCH in R17, support separate coding for the two HARQ-ACKs.
· It is understood that it is intended that the number of encoding chains for all UCI multiplexing combinations in Rel-17 should not exceed that in Rel-15/16.
Including any RAN1 involvement in propagation delay compensation enhancements (including mobility issues, if any).
R1-2102396 Enhancement for support of time synchronization OPPO
R1-2102497 Discussion on propagation delay compensation enhancements ZTE
R1-2102525 Discussion on propagation delay compensation enhancements vivo
R1-2102632 Discussion on propagation delay compensation enhancements CATT
R1-2102698 Discussion on propagation delay compensation for time synchronization MediaTek Inc.
R1-2102748 Propagation Delay Compensation Enhancements for Time Synchronization Ericsson
R1-2102821 Discussion on enhancements for propagation delay compensation Nokia, Nokia Shanghai Bell
R1-2103031 Further analysis and design considerations regarding propagation delay compensation Intel Corporation
R1-2103167 Enhancements for support of time synchronization for enhanced IIoT and URLLC Qualcomm Incorporated
R1-2103240 Discussion for propagation delay compensation enhancements Samsung
R1-2103328 Propagation delay compensation enhancements ETRI
R1-2103351 Discussion on propagation delay compensation enhancements LG Electronics
R1-2103398 Enhancements for support of time synchronization Huawei, HiSilicon, SIA
[104b-e-NR-R17-IIoT_URLLC-05] – Chengyan (Huawei)
Email discussion on propagation delay compensation enhancements
- 1st check point: 4/15
- 2nd check point: 4/19
- 3rd check point: 4/20
R1-2103775 Feature lead summary#1 on propagation delay compensation enhancements Moderator (Huawei)
Agreements: If downlink frame timing detection error needs to be considered separately from propagation delay estimation error, take ±100 ns as the assumption for downlink frame timing detection error (errorUE,DL,RX) at the UE for evaluation of the overall time synchronization error for RTT based propagation delay compensation.
R1-2103890 Feature lead summary#2 on propagation delay compensation enhancements Moderator (Huawei)
R1-2103945 Feature lead summary#3 on propagation delay compensation enhancements Moderator (Huawei)
Decision: As per email decision posted on April 20th,
Agreements: Take the following equation for evaluation of the DL propagation delay estimation error for TA based propagation delay compensation:
· Either option 1 or option 2 below will be applied based on the RAN4 reply to RAN1 LS R1-2102245.
o Option 1: errorUE, DL,RX+errorUE, UL, TX <= Te
o Option 2: errorUE, UL, TX = Te and errorUE, DL,RX is equal to a value separate from Te
· FFS whether errorBS,DL,TX in the above equation should be included or not.
Agreements:
R1-2104066 Feature lead summary#4 on propagation delay compensation enhancements Moderator (Huawei)
Decision: As per email decision posted on April 20th,
Working assumption:
Agreement:
Take the following as the evaluation assumptions for both RTT-based PDC and TA-based PDC.
Agreement:
Existing DL reference signal(s) are used for Rx – Tx time difference estimation at UE side for RTT-based propagation delay compensation, if RTT-based propagation delay compensation is supported.
Conclusion:
Final feature lead summary in R1-2104136.
Please refer to RP-210854 for detailed scope of the WI
Please also refer to RP-202872 for additional guidance for this e-meeting
Only to handle topics of PUCCH carrier switching and retransmission of cancelled HARQ
R1-2104217 HARQ-ACK Enhancements for IIoT/URLLC Ericsson
R1-2104262 UE feedback enhancements for HARQ-ACK Huawei, HiSilicon
R1-2104309 HARQ-ACK Feedback Enhancements for URLLC/IIoT Nokia, Nokia Shanghai Bell
R1-2104326 Discussion on HARQ-ACK enhancements for eURLLC ZTE
R1-2104353 HARQ-ACK enahncements for Rel-17 URLLC vivo
R1-2104420 Discussion on HARQ-ACK feedback enhancements for Rel-17 URLLC Spreadtrum Communications
R1-2104512 UE feedback enhancements for HARQ-ACK CATT
R1-2104604 Discussion on UE feeback enhancements for HARQ-ACK CMCC
R1-2104663 HARQ-ACK enhancement for IOT and URLLC Qualcomm Incorporated
R1-2104802 HARQ-ACK enhancements for Rel-17 URLLC/IIoT OPPO
R1-2104854 Discussion on two aspects of UE HARQ-ACK feedback enhancements China Telecom
R1-2104899 On dynamic carrier switching and dropped HARQ feedback retransmission Intel Corporation
R1-2105097 Views on eIIoT/URLLC HARQ feedback enhancements Apple
R1-2105160 Retransmission of dropped HARQ-ACK for URLLC Sony
R1-2105188 Discussion on UE feedback enhancements for HARQ-ACK PANASONIC R&D Center Germany
R1-2105212 UE feedback enhancements for HARQ-ACK ETRI
R1-2105258 UE feedback enhancements for HARQ-ACK NEC
R1-2105302 HARQ-ACK Reporting Enhancements for URLLC Samsung
R1-2105399 HARQ feedback enhancements for IIoT and URLLC InterDigital, Inc.
R1-2105425 Discussion on UE feedback enhancement for HARQ-ACK LG Electronics
R1-2105631 UE feedback enhancements for HARQ-ACK Sharp
R1-2105693 Discussion on HARQ-ACK feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
R1-2105732 On UE feedback enhancements for HARQ-ACK MediaTek Inc.
R1-2105750 UE feedback enhancements for HARQ-ACK CAICT
R1-2105766 HARQ-ACK feedback enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2105819 Discussion on UE feedback enhancements for HARQ-ACK Asia Pacific Telecom, FGI
R1-2105872 Discussion on HARQ-ACK enhancement for URLLC/IIoT WILUS Inc.
R1-2104314 Moderator summary #1 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
[105-e-NR-R17-IIoT-URLLC-01] – Klaus (Nokia)
Email discussion on UE feedback enhancements for HARQ-ACK
R1-2106097 Moderator summary #2 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
R1-2106248 Moderator summary #4 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
From GTW sessions:
Agreement: Support PUCCH carrier switching based on dynamic indication in DCI scheduling a PUCCH and semi-static configuration
· Details are FFS (including applicability of dynamic and/or semi-static means)
· Aim for minimum specification impact
· Dynamic indication and/or semi-static configuration are subject to separate UE capabilities
· The semi-static PUCCH carrier switching configuration operation is based on RRC configured PUCCH cell timing pattern of applicable PUCCH cells and supports PUCCH carrier switching across cells with different numerologies.
o FFS whether additional rules are needed to support PUCCH carrier switching across cells with different numerologies
· FFS the maximum number of PUCCH cells
· FFS whether and how to support joint operation of dynamic and semi-static carrier switching for a UE
· FFS whether and how to support joint operation of PUCCH carrier switching and SPS HARQ-ACK deferral
Decision: As per email decision posted on May 27th,
Working Assumption: For at least HARQ-ACK re-transmission:
Decision: As per email decision posted on May 27th,
Agreement: For PUCCH carrier switching, the PUCCH resource configuration is per UL BWP (i.e. per candidate cell and UL BWP of that specific candidate cell).
Agreement: For PUCCH carrier switching based on dynamic indication in DCI scheduling a PUCCH (i.e. Alt. 1), the PDSCH to HARQ-ACK offset k1 is interpreted based on the numerology of the dynamically indicated target PUCCH cell.
R1-2106249 Final moderator summary on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
R1-2104199 CSI feedback enhancements for URLLC FUTUREWEI
R1-2104218 CSI Feedback Enhancements for IIoT/URLLC Ericsson
R1-2104263 CSI feedback enhancements Huawei, HiSilicon
R1-2104327 Discussion on CSI feedback enhancements for eURLLC ZTE
R1-2104354 CSI feedback enhancements for Rel-17 URLLC vivo
R1-2104421 Discussion on CSI feedback enhancements for Rel-17 URLLC Spreadtrum Communications
R1-2104513 CSI feedback enhancements CATT
R1-2104605 Discussion on CSI feeback enhancements for URLLC CMCC
R1-2104664 CSI enhancement for IOT and URLLC Qualcomm Incorporated
R1-2104803 CSI feedback enhancements for URLLC OPPO
R1-2105958 Selection of enhanced CSI feedback schemes Intel Corporation (rev of R1-2104900)
R1-2105098 Views on eIIoT/URLLC CSI feedback enhancements Apple
R1-2105161 Considerations on CSI feedback enhancements Sony
R1-2105186 Discussion on CSI Feedback Enhancements Quectel, Langbo
R1-2105303 Improving MCS Selection for URLLC Samsung
R1-2105426 Discussion on CSI feedback enhancements for URLLC LG Electronics
R1-2105472 CSI feedback enhancements InterDigital, Inc.
R1-2106003 CSI feedback enhancements for URLLC/IIoT use cases (revised) Nokia, Nokia Shanghai Bell (rev of R1-2105580)
R1-2105694 Discussion on CSI feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
R1-2105733 CSI feedback enhancements for URLLC MediaTek Inc.
R1-2105767 CSI feedback enhancements for URLLC/IIoT Lenovo, Motorola Mobility
[105-e-NR-R17-IIoT-URLLC-02] – Paul (InterDigital)
Email discussion on CSI feedback enhancements
R1-2105975 Feature lead summary#1 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
R1-2105976 Feature lead summary#2 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
R1-2106176 Feature lead summary#3 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
RAN1 to further investigate the following for CSI enhancements for IIoT/URLLC:
· Increasing granularity of subband CQI (3-bits differential subband CQI or 4-bits CQI)
· Reporting of delta-MCS:
§ Report consists of delta-MCS for a TB received with MCS index IMCS:
§ delta-MCS is calculated from the difference between IMCS_tgt and IMCS, where IMCS_tgt is largest MCS index such that estimated BLER for a TB received with this MCS index would be smaller than or equal to a BLER target, and IMCS is the MCS index of the received TB.
§ Estimated BLER for a TB is the largest error probability estimate of a code block within a TB.
§ FFS: whether to apply additional offset to delta-MCS (i.e. delta-MCS = IMCS_tgt – IMCS - offset)
§ FFS: whether TB size for determining IMCS_tgt is TB size of received TB or other TB size
§
FFS: How UE determines BLER
target (e.g. explicitly indicated by network or linked to a CQI table)
o FFS: Number of bits and quantization for delta-MCS report
o FFS: whether delta-MCS is reported (Option 1) jointly with HARQ-ACK codebook or (Option 2) separately from HARQ-ACK codebook.
Supported by: SONY, MediaTek, OPPO, Spreadtrum, HiSilicon, CATT, InterDigital, Ericsson, Quectel, DoCoMo, Samsung, Motorola Mobility, LG, ZTE, vivo, Fujitsu, Qualcomm
Objected by: Nokia, Futurewei
Final summary in:
R1-2106177 Feature lead summary#4 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
Only to handle topics of CG harmonization and decision between Alt-a/Alt-b for semi-static channel access mode when a UE can operate as UE-initiated COT for both CG and DG (see sections 2.3/2.4/2.5 of R1-2103960)
R1-2104200 UE initiated COT for semi-static channel access FUTUREWEI
R1-2104219 Enhancements for IIoT/URLLC on Unlicensed Band Ericsson
R1-2104265 Uplink enhancements for URLLC in unlicensed controlled environments Huawei, HiSilicon
R1-2104328 Discussion on unlicensed band URLLC/IIoT ZTE
R1-2104355 Enhancements for unlicensed band URLLC/IIoT vivo
R1-2104422 Discussion on enhancements for unlicensed band URLLC/IIoT Spreadtrum Communications
R1-2104514 Enhancements for unlicensed band URLLC/IIoT CATT
R1-2104665 Uplink enhancements for URLLC in unlicensed controlled environments Qualcomm Incorporated
R1-2104804 Enhancements for unlicensed band URLLC/IIoT OPPO
R1-2104901 On the Harmonization of UL CG between NR-U and URLLC and COT-initiator Determination Intel Corporation
R1-2105099 URLLC uplink enhancements for unlicensed spectrum Apple
R1-2105142 Further UL enhancements for IIoT/URLLC in unlicensed controlled environment Nokia, Nokia Shanghai Bell
R1-2105143 Enhancements for unlicensed band URLLC/IIoT Panasonic Corporation
R1-2105162 Considerations on unlicensed URLLC Sony
R1-2105213 Enhancements for unlicensed band URLLC/IIoT ETRI
R1-2105304 Enhancements for unlicensed band URLLC/IIoT Samsung
R1-2105400 Enhancements for unlicensed band URLLC/IIoT InterDigital, Inc.
R1-2105409 Enhancements for unlicensed band URLLC/IIoT NEC
R1-2105427 Discussion on unlicensed band URLLC/IIOT LG Electronics
R1-2105632 Enhancements for unlicensed band URLLC/IIoT Sharp
R1-2105695 Discussion on enhancements for unlicensed band URLLC NTT DOCOMO, INC.
R1-2105734 On the enhancements for unlicensed band URLLC/IIoT MediaTek Inc.
R1-2105768 Enhancements for unlicensed band URLLC/IIoT Lenovo, Motorola Mobility
R1-2105873 Discussion on enhancement for unlicensed URLLC/IIoT WILUS Inc.
//Handled under NWM – See RAN1-105-e-NWM-NR-R17-IIoT-URLLC-03 as the document name
[105-e-NR-R17-IIoT-URLLC-03] – Sorour (Ericsson)
Email discussion on enhancements for unlicensed band URLLC/IIoT
R1-2106044 Summary#1 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
R1-2106045 Summary#2 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
R1-2106046 Summary#3 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
R1-2106047 Summary#4 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
Agreement:
Agreement:
Down-select one of the following options (target RAN1#104-e):
· Option 1: Both “CG-UCI based procedures” and “CG-DFI based procedures” are enabled or disabled for unlicensed using one RRC parameter i.e. cg-RetransmissionTimer-r16.
· Option 2-a: “CG-UCI based procedures” and “CG-DFI based procedures” are independently enabled or disabled for unlicensed using respective RRC parameter, i.e. new parameter X and cg-RetransmissionTimer-r16, respectively.
o If cg-RetransmissionTimer-r16 is configured, “CG-UCI based procedures” should also be enabled by X.
· Note: Procedures based on CG-UCI rely on UE including CG-UCI in CG PUSCH at least as in Rel-16 where the values of the respective fields of CG-UCI are decided by UE.
· Note: Procedures based on CG-DFI rely on automatic re-transmission on CG configuration and reception of CG downlink feedback information (DFI) in DCI for re-transmissions
· Alt-a is taken in the following agreement:
Agreement:
In semi-static channel access mode when a UE can operate as UE-initiated COT,
· Select one of the following alternatives to determine whether a configured UL transmission that is aligned with a UE FFP boundary and ends before the idle period of that UE FFP, is based on UE-initiated COT or sharing a gNB-initiated COT:
o Alt-a: If the transmission is confined within a gNB FFP before the idle period of that gNB FFP, and the UE has already determined that gNB is initiated that gNB FFP, UE assumes that the configured UL transmission corresponds to gNB-initiated COT. Otherwise, UE assumes that the configured UL transmission corresponds to UE-initiated COT
o Alt-b: The UE assumes that the configured UL transmission corresponds to UE-initiated COT..
Agreement:
In semi-static channel access mode when a UE can operate as initiating device,
· Select one of the following alternatives to determine whether a scheduled UL transmission is based on UE-initiated COT or sharing a gNB-initiated COT:
· Alt-a: Determination based on the content in the scheduling DCI
· FFS on whether the corresponding field(s) can be absent in DCI
§ If absent, determination based on the rules applied for configured UL transmissions is applied
· FFS whether/how to handle the case when the gNB schedules an UL transmission in the next gNB’s FFP period
· Alt-b: Determination based on the rules applied for a configured UL transmission
Final summary in:
R1-2106048 Summary#5 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
R1-2104220 Intra-UE Multiplexing/Prioritization Enhancements for IIoT/URLLC Ericsson
R1-2104264 Intra-UE multiplexing enhancements Huawei, HiSilicon
R1-2104310 On UL intra-UE prioritization and multiplexing enhancements Nokia, Nokia Shanghai Bell
R1-2104329 Discussion on enhanced intra-UE multiplexing ZTE
R1-2104356 Intra-UE Multiplexing/Prioritization for Rel-17 URLLC vivo
R1-2104423 Discussion on intra-UE multiplexing/prioritization Spreadtrum Communications
R1-2104515 Intra-UE multiplexing and prioritization CATT
R1-2104606 Discussion on intra-UE multiplexing/prioritization CMCC
R1-2104666 Intra-UE multiplexing and prioritization for IOT and URLLC Qualcomm Incorporated
R1-2104805 Enhancements on intra-UE multiplexing/prioritization OPPO
R1-2104855 Discussion on intra-UE multiplexing and prioritization China Telecom
R1-2104902 Details of intra-UE multiplexing and prioritization Intel Corporation
R1-2106120 Design of Rel-17 intra-UE multiplexing/prioritization Apple (rev of R1-2105100)
R1-2105144 Discussion on Intra-UE multiplexing and prioritization of different priority Panasonic Corporation
R1-2105163 Considerations on intra-UE UL multiplexing Sony
R1-2105187 Discussion on Intra-UE Multiplexing/Prioritization Quectel, Langbo
R1-2105206 Intra-UE Multiplexing and Prioritization TCL Communication Ltd.
R1-2105221 Intra-UE Multiplexing/Prioritization ETRI
R1-2105262 Discussion on Intra-UE prioritization and multiplexing NEC
R1-2105305 Uplink intra-UE multiplexing and prioritization Samsung
R1-2105428 Discussion on Intra-UE multiplexing/prioritization LG Electronics
R1-2105473 Intra-UE multiplexing and prioritization InterDigital, Inc.
R1-2105558 Intra-UE multiplexing prioritization for URLLC IIoT Xiaomi
R1-2105633 Intra-UE UCI multiplexing with different priorities and channel prioritization Sharp
R1-2105696 Discussion on intra-UE multiplexing/prioritization for Rel.17 URLLC NTT DOCOMO, INC.
R1-2105735 Methods for intra-UE multiplexing and prioritization MediaTek Inc.
R1-2105756 Discussion on intra-UE multiplexing ITRI
R1-2105769 Intra-UE multiplexing enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2105874 Discussion on intra-UE multiplexing/prioritization for URLLC/IIoT WILUS Inc.
[105-e-NR-R17-IIoT-URLLC-04] – Jia (OPPO)
Email discussion on intra-UE multiplexing/prioritization
R1-2106051 Summary#1 of email thread [105-e-NR-R17-IIoT_URLLC-04] Moderator (OPPO)
From GTW sessions:
Agreement:
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a PUCCH in R17, when the total number of LP and HP HARQ-ACK bits is more than 2,
Agreement:
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a PUCCH in R17, when the total number of LP and HP HARQ-ACK bits is 2, treat the two bits as HARQ-ACK bits with High priority.
· Rel-15 design (for PF0 and PF1) is baseline.
· Note: Qualcomm has strong concern on above scheme. The scheme cannot provide unequal error protection between the HP bit and LP bit hence could suffer from performance degradation for the HP bit. Qualcomm accepts the scheme for the sake of progress in RAN 1 with the concern on the performance reserved.
Final summary in:
R1-2106063 Summary#2 of email thread [105-e-NR-R17-IIoT_URLLC-04] Moderator (OPPO)
Including any RAN1 involvement in propagation delay compensation enhancements (including mobility issues, if any).
Void (not be handled during this e-meeting). No contributions please.
Please refer to RP-210854 for detailed scope of the WI
Please also refer to section 3.2 of RP-211569 for additional guidance for this e-meeting
R1-2106490 UE feedback enhancements for HARQ-ACK Huawei, HiSilicon
R1-2106586 HARQ-ACK enhancements for Rel-17 URLLC vivo
R1-2106636 HARQ-ACK Feedback Enhancements for URLLC/IIoT Nokia, Nokia Shanghai Bell
R1-2106678 HARQ-ACK Enhancements for IIoT/URLLC Ericsson
R1-2106697 Discussion on HARQ-ACK feedback enhancements for Rel-17 URLLC Spreadtrum Communications
R1-2106734 Discussion on HARQ-ACK enhancements for eURLLC ZTE
R1-2106801 Considerations on HARQ-ACK enhancements for URLLC Sony
R1-2106879 On HARQ-ACK reporting enhancements Samsung
R1-2106962 UE feedback enhancements for HARQ-ACK CATT
R1-2107025 Discussion on UE feedback enhancements for HARQ-ACK Panasonic
R1-2107133 Discussion on UE feedback enhancements for HARQ-ACK China Telecom
R1-2107156 UE feedback enhancements for HARQ-ACK NEC
R1-2107180 HARQ-ACK feedback enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2107272 HARQ-ACK enhancements for Rel-17 URLLC/IIoT OPPO
R1-2107296 Discussion on UE feedback enhancements for HARQ-ACK FGI, Asia Pacific Telecom
R1-2107336 HARQ-ACK enhancement for IOT and URLLC Qualcomm Incorporated
R1-2107397 Discussion on UE feeback enhancements for HARQ-ACK CMCC
R1-2107443 Discussion on UE feedback enhancement for HARQ-ACK LG Electronics
R1-2107472 UE feedback enhancements for HARQ-ACK ETRI
R1-2107491 On UE feedback enhancements for HARQ-ACK MediaTek Inc.
R1-2107583 Design aspects for the agreed HARQ feedback enhancements Intel Corporation
R1-2107639 HARQ enhancements for IIoT and URLLC InterDigital, Inc.
R1-2107732 HARQ Feedback Enhancements for URLLC Apple
R1-2107791 UE feedback enhancements for HARQ-ACK Sharp
R1-2107833 UE feedback enhancements for HARQ-ACK TCL Communication Ltd.
R1-2107851 Discussion on HARQ-ACK feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
R1-2107917 UE feedback enhancements for HARQ-ACK Xiaomi
R1-2108152 Discussion on HARQ-ACK enhancement for URLLC/IIoT WILUS Inc.
R1-2108162 UE feedback enhancements for HARQ-ACK CAICT
[106-e-NR-R17-IIoT-URLLC-01] – Klaus (Nokia)
Email discussion on UE feedback enhancements for HARQ-ACK
- 1st check point: August 19
- 2nd check point: August 25
- 3rd check point: August 27
R1-2106639 Moderator summary #1 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
From GTW session:
Agreement
The SPS HARQ-ACK deferral is enabled per SPS configuration
· Note: part of sps-config, only HARQ-ACK of SPS PDSCH configurations enabled for deferral is in principle subject to deferral
Agreement
Definition of when to defer from the initial slot:
· Alt1: Deferral only, if the SPS HARQ-ACK in the initial slot/sub-slot cannot be transmitted as the resulting PUCCH resource for transmission using the PUCCH by SPS-PUCCH-AN-List-r16 or n1PUCCH-AN is not valid
Agreement
Update the following RAN1#105-e agreement as (RED):
·
RAN1#105-e Agreement: For
PUCCH carrier switching, the PUCCH resource configuration (i.e. pucch-Config
/ PUCCH-ConfigurationList) is per UL BWP (i.e. per candidate cell
and UL BWP of that specific candidate cell).
o FFS: CSI and SR
Decision: As per email decision posted on Aug 20th,
Agreement
For SPS HARQ-ACK deferral, the maximum deferral value in terms of k1+k1def is RRC configured per SPS configuration.
Agreement
For SPS HARQ-ACK deferral, only SPS HARQ bits subject to deferral from HARQ-ACK codebook from an initial PUCCH slot are deferred to the target PUCCH slot.
Agreement
For SPS HARQ-ACK deferral, deferred SPS HARQ bits from more than one ‘initial PUCCH slot’ can be jointly deferred to a target PUCCH slot.
Agreement
Confirm the following RAN1#105-e working assumption:
For at least HARQ-ACK re-transmission:
Agreement
Support PHY priority handling for a PUCCH carrying the Rel-17 enhanced Type 3 HARQ-ACK CB of smaller size.
Agreement
Support PHY priority handling for a PUCCH carrying the Rel-16 Type 3 HARQ-ACK CB in Rel-17.
Agreement
For the PHY priority handling of the enhanced Type 3 CB(s) of smaller size, the enhanced Type 3 HARQ-ACK has the same structure, size and content (in terms of HARQ-IDs, CCs) irrespective of the PHY priority.
Agreement
Support Rel-17 enhanced Type 3 HARQ-ACK CB of smaller size triggering using DCI format 1_2 for a UE supporting DCI format 1_2.
· The triggering support for DCI format 1_2 is independently (from triggering using DCI format 1_1) RRC configured to the UE.
Agreement
Support Rel-16 Type 3 HARQ-ACK CB triggering using DCI format 1_2 in Rel-17 for a UE supporting DCI format 1_2.
· The support is subject to a Rel-17 UE capability and a UE supporting this capability can be configured with DCI format 1_2 triggering of the Rel-16 Type 3 HARQ-ACK CB.
Agreement
For the enhanced Type 3 HARQ-ACK CB of smaller size triggered in a PUCCH slot, the UE is not expecting HARQ-ACK information in a Type 1 or Type 2 HARQ-ACK CB to be transmitted that cannot be mapped to the enhanced Type 3 HARQ-ACK CB of smaller size as the HARQ process is not part of the codebook.
Agreement
The DCI triggering (by a DL assignment) the one-shot HARQ-ACK re-transmission on a PUCCH resource other than enhanced Type 2 or (enhanced) Type 3 HARQ-ACK CB dynamically indicates the HARQ-ACK codebook(s) / PUCCH occasions to be re-transmitted.
· FFS details
Agreement
A single DCI triggering the Rel-17 one-shot triggering (by a DL assignment) of HARQ-ACK re-transmission on a PUCCH resource other than enhanced Type 2 or (enhanced) Type 3 HARQ-ACK CB can trigger the re-transmission of HARQ-ACK information of only a single HARQ-ACK CB.
Agreement
The Rel-17 one-shot triggering (by a DL assignment) of HARQ-ACK re-transmission on a PUCCH resource other than enhanced Type 2 or (enhanced) Type 3 HARQ-ACK CB is done through an explicit triggering indication in the DCI through a DCI field.
Agreement
Support PHY priority handling for the Rel-17 one-shot triggering (by a DL assignment) of HARQ-ACK re-transmission on a PUCCH resource other than enhanced Type 2 or (enhanced) Type 3 HARQ-ACK CB.
Conclusion
The dynamic repetition indication solution for slot-based PUCCH repetition from the RAN1#105-e working assumption from Cov. Enh. WI can be directly applied for dynamic repetition indication for sub-slot based PUCCH repetition.
Agreement
For sub-slot based PUCCH repetition for HARQ-ACK, semi-static configured PUCCH repetition (i.e. using nrofSlots) and dynamic repetition factor based operation is supported.
R1-2108440 Moderator summary #2 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
From GTW session:
Agreement
For SPS HARQ-ACK deferral, the target PUCCH slot is defined as the next PUCCH slot where sps-PUCCH-AN-List-r16 or n1PUCCH-AN PUCCH resource is regarded as valid, or a PUCCH resource (from PUCCH-ResourceSet, i.e. DG PDSCH HARQ multiplexed) is dynamically indicated
· The target PUCCH slot determination is based on the total HARQ-ACK payload size including deferred SPS HARQ-ACK information and non-deferred HARQ-ACK information (if any) of a candidate target PUCCH slot
· The final PUCCH resource selection in the target PUCCH slot in terms of PUCCH resource set and PUCCH resource ID follows the Rel-16 procedures.
Agreement
For SPS HARQ-ACK deferral, if after the target PUCCH slot determination the deferred SPS HARQ-ACK cannot be transmitted, the deferred SPS HARQ-ACK bits are not further deferred and are dropped.
Agreement
For SPS HARQ-ACK deferral, in the target PUCCH slot the deferred SPS HARQ-ACK bits are appended to the initial HARQ bits / Type 1 or Type 2 codebook.
R1-2108546 Moderator summary #3 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
Decision: As per email decision posted on Aug 28th,
Agreement
For SPS HARQ-ACK deferral, confirm the RAN1#104b-e working assumption with the following updates in RED:
(working assumption) To handle the collision for the same HARQ process due to deferred SPS HARQ-ACK the following behaviour is to be specified:
-
In case the UE is expected to receives
PDSCH of a certain HARQ Process ID according to TS
38.214 Sec. 5.1, the deferred SPS HARQ bit(s) for this HARQ Process ID
are dropped.
Agreement
For enh. Type 3 HARQ-ACK CB(s), support dynamic selection based on indication in the triggering DCI of one of at least one enh. Type 3 HARQ-ACK CB(s).
Agreement
The following enhanced Type 3 CB types of smaller size are supported, the CB to contain either:
FFS: additional enh. Type 3 CB types
Agreement
For Rel-17 one-shot triggering for HARQ-ACK re-transmission, the UE does not expect more than one triggering DCI for Rel-17 one-shot feedback indicating the same PUCCH slot for the re-transmission of HARQ-ACK CBs of different PUCCH slots to be re-transmitted
Agreement
Support slot-based PUCCH repetition for PUCCH Format 0 and Format 2 also for single TRP operation.
· The support is subject to independent UE capability indication
Agreement
In addition to HARQ-Ack of PDSCH dynamically scheduled by a DCI indicating a PUCCH carrier, the dynamic target carrier indication also applies to:
Agreement
Semi-static PUCCH carrier switching is applicable to all UCI types incl. HARQ-ACK, SR and CSI.
Final summary in R1-2108547.
R1-2106491 CSI feedback enhancements Huawei, HiSilicon
R1-2106587 CSI feedback enhancements for Rel-17 URLLC vivo
R1-2106679 CSI Feedback Enhancements for IIoT/URLLC Ericsson
R1-2106698 Discussion on CSI feedback enhancements Spreadtrum Communications
R1-2106735 Discussion on CSI feedback enhancements for eURLLC ZTE
R1-2106802 Considerations on CSI enhancements for URLLC Sony
R1-2106837 Discussion on CSI Feedback Enhancements Quectel, Langbo
R1-2106880 UE Feedback Enhancements for URLLC Samsung
R1-2106963 CSI feedback enhancements CATT
R1-2107019 CSI feedback enhancements for URLLC/IIoT use cases Nokia, Nokia Shanghai Bell
R1-2108237 CSI feedback enhancements InterDigital, Inc. (rev of R1-2107074)
R1-2107078 CSI feedback enhancements for URLLC FUTUREWEI
R1-2107185 CSI feedback enhancements for URLLC/IIoT Lenovo, Motorola Mobility
R1-2107273 CSI feedback enhancements for URLLC OPPO
R1-2107337 CSI enhancement for IOT and URLLC Qualcomm Incorporated
R1-2107398 Discussion on CSI feeback enhancements for URLLC CMCC
R1-2107444 Discussion on CSI feedback enhancements for URLLC LG Electronics
R1-2107492 CSI feedback enhancements for URLLC MediaTek Inc.
R1-2107584 On enhanced SB CQI reporting granularity and delta-MCS reporting Intel Corporation
R1-2107733 CSI feedback enhancements for URLLC Apple
R1-2107852 Discussion on CSI feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
R1-2108012 Views for Increasing Granularity of Subband CQI ITRI
[106-e-NR-R17-IIoT-URLLC-02] – Paul (InterDigital)
Email discussion on CSI feedback enhancement
- 1st check point: August 19
- 2nd check point: August 25
- 3rd check point: August 27
R1-2108235 Feature lead summary #1 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
R1-2108236 Feature lead summary #2 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
Agreement
For subband CQI reporting with more than 2 bits per subband
· Support 4-bits CQI only
R1-2108449 Feature lead summary #3 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital)
Agreement
For subband CQI reporting in Rel-17, RRC can configure use of legacy 2-bits D-CQI or 4-bits CQI for each CSI report configuration.
· This feature is subject to UE capability
· FFS: Whether wideband CQI report can be omitted
R1-2108450 Feature lead summary #4 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital)
Conclusion
· There is no consensus in RAN1 on the support of delta-MCS in Rel-17.
R1-2106493 Uplink enhancements for URLLC in unlicensed controlled environments Huawei, HiSilicon
R1-2106588 Enhancements for unlicensed band URLLC/IIoT vivo
R1-2106680 Enhancements for IIoT/URLLC on Unlicensed Band Ericsson
R1-2106699 Discussion on enhancements for unlicensed band URLLC/IIoT Spreadtrum Communications
R1-2106736 Discussion on unlicensed band URLLC/IIoT ZTE
R1-2106764 UL enhancements for IIoT/URLLC in unlicensed controlled environment Nokia, Nokia Shanghai Bell
R1-2106803 Considerations on Unlicensed URLLC Sony
R1-2106881 Enhancements for unlicensed band URLLC/IIoT Samsung
R1-2106964 Discussion on remaining issues on enhancements for unlicensed band URLLC/IIoT CATT
R1-2107013 Enhancements for unlicensed band URLLC/IIoT NEC
R1-2107103 UE initiated COT for semi-static channel access FUTUREWEI
R1-2107114 Enhancements for unlicensed band URLLC/IIoT Panasonic Corporation
R1-2107186 Enhancements for unlicensed band URLLC/IIoT Lenovo, Motorola Mobility
R1-2107274 Enhancements for unlicensed band URLLC/IIoT OPPO
R1-2107294 Enhancements for unlicensed band URLLC/IIoT FGI, Asia Pacific Telecom
R1-2107338 Uplink enhancements for URLLC in unlicensed controlled environments Qualcomm Incorporated
R1-2107445 Discussion on unlicensed band URLLC/IIOT LG Electronics
R1-2107473 Enhancements for unlicensed band URLLC/IIoT ETRI
R1-2107493 On the enhancements for unlicensed band URLLC/IIoT MediaTek Inc.
R1-2107585 On the Details for Enabling URLLC/IIoT in Unlicensed Band Intel Corporation
R1-2107640 Enhancements for unlicensed band URLLC/IIoT InterDigital, Inc.
R1-2107734 URLLC uplink enhancements for unlicensed spectrum Apple
R1-2107792 Enhancements for unlicensed band URLLC/IIoT Sharp
R1-2107853 Discussion on enhancements for unlicensed band URLLC NTT DOCOMO, INC.
R1-2108153 Discussion on enhancement for unlicensed URLLC/IIoT WILUS Inc.
[106-e-NR-R17-IIoT-URLLC-03] – Sorour (Ericsson)
Email discussion on unlicensed band URLLC/IIoT
- 1st check point: August 19
- 2nd check point: August 25
- 3rd check point: August 27
R1-2108301 Summary#1 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
R1-2108302 Summary#2 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
R1-2108303 Summary#3 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
Agreement
In semi-static channel access mode, the content in a scheduling DCI that indicates the assumption on the COT-initiator for the scheduled transmission is determined based on the channel access field in the DCI.
Agreement
In semi-static channel access mode,
· The inclusion of the channel access field in Rel-16 DCI 0_1 and 1_1 in Rel-17 DCI 0_2 and 1_2, respectively, is supported.
Agreement
In semi-static channel access mode, the size of channel access field in a scheduling DCI with format 0_0/1_0, 0_1/1_1, 0_2/1_2 is 2 bits.
Agreement
In semi-static channel access mode, a DL transmission burst based on sharing of a UE initiated COT corresponding to a UE FFP, shall include at least scheduled DL transmission or a DCI intended for the UE that initiated that FFP.
Decision: As per email decision posted on Aug 21st,
Conclusion
Any UL or DL transmission that is expected to occur, should be associated to a Channel Occupancy (CO) with a corresponding FFP. When a transmission is associated to a CO with a corresponding FFP:
· The association of the transmission to a CO with corresponding FFP is based on either of the following assumption:
o “Initiating COT”: This assumption implies that the transmission would initiate a CO corresponding the FFP.
o “Sharing COT”: This assumption implies that the transmission would share a CO corresponding to the FFP.
· The association assumption is validated as follows:
o “Initiating COT” assumption is validated if the transmission would start at the FFP boundary and would end before idle period of the FFP.
o “Sharing COT” assumption is validated if the transmission would start after the FFP boundary and would end before idle period of the FFP and the CO corresponding to the FFP is initiated.
· A transmission based on a CO association assumption can occur if the CO association assumption is validated and if the following sensing conditions are met:
o For CO association assumption as “Initiating COT”:
§ If a CCA is successful before the transmission.
o For CO association assumption as “Sharing COT”
§ If the gap between the beginning of the transmission and the end of previous one sharing the same CO in that FFP is more than 16us and if a CCA is successful before the transmission.
§ IF the gap between the beginning of the transmission and the end of previous one sharing the same CO in that FFP is at most 16us
R1-2108304 Summary#4 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
Agreement
In semi-static channel access mode, the content of the channel access field in a DCI scheduling a UL transmission for a UE determines an index to a row in Table 1 with Alt-1 (Option 1)
TABLE 1
|
Bit field mapped to index |
Channel Access Type |
The CP extension T_"ext" index defined in Clause 5.3.1 of [4, TS 38.211] |
Initiator of a channel occupancy associated to UL transmission described in Clause x.x in TS 37.213 |
|
0 |
No sensing as defined in Clause 4.3 in TS 37.213 |
0 |
Alt-1:gNB Alt-2: UE-initiated COT if condition A, otherwise gNB’s COT |
|
1 |
No sensing as defined in Clause 4.3 in TS 37.213 |
2 |
Alt-1:gNB Alt-2: UE-initiated COT if condition A, otherwise gNB’s COT |
|
2 |
9us sensing within a 25us interval as defined in Clause 4.3 in TS 37.213 |
0 |
gNB |
|
3 |
9us sensing [within a 25us interval] as defined in Clause 4.3 in TS 37.213 |
0 |
UE |
Note: The last row in Table 1 is only applicable when the UE can operate as an initiating device as configured by gNB.
Agreement
In semi-static channel access mode, when the gNB schedules by a DCI a UL transmission in a later g-FFP that is different from the g-FFP that carries the scheduling DCI:
· The UE follows the indicated COT initiator as the following:
o If the UE validates the indicated COT initiator assumption and satisfies the applicable sensing conditions, the transmission occurs. Otherwise, the transmission is dropped.
Conclusion
There is no consensus in RAN1 to support UE-initiated COT for semi-static channel occupancy in IDLE/INACTIVE mode.
R1-2108305 Summary#5 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
Agreement
Do not support PUSCH repetition Type B based on NR-U Rel-16 CG for unlicensed band operation.
Agreement
Replace “9us sensing [within a 25us interval] as defined in Clause 4.3 in TS 37.213” with “9us sensing as defined in Clause x.x in TS 37.213” in the last row of Table 1 in the previous agreement and add the following notes to Table 1:
· Note 1: The intention of Clause x.x above is to describe the LBT procedure from a UE perspective when this operates as initiating device.
·
Note 2: A UE operating as
initiating device may transmit an UL transmission burst(s) within its u-FFP
immediately after sensing the channel to be idle for at least a sensing slot
duration 
if the
gap between the UL transmission burst(s) and any previous transmission burst is
more than 
Agreement
When a UE operates as an initiating device, and the gNB shares a UE’s FFP for DL transmission, regardless of the gap between any UL and DL bursts, no restriction is imposed on the maximum duration of each of the DL bursts such that each can continue until the UE FFP idle period starts.
· Note: The applicability of the EDT calculation based on the UE’s transmit power to the UE COT initiation in accordance to the UL-DL gap duration and/or the content of the DL burst is separately discussed
Final summary in R1-2108306.
R1-2106492 Intra-UE multiplexing enhancements Huawei, HiSilicon
R1-2106589 Intra-UE Multiplexing/Prioritization for Rel-17 URLLC vivo
R1-2106637 On UL intra-UE prioritization and multiplexing enhancements Nokia, Nokia Shanghai Bell
R1-2106681 Intra-UE Multiplexing/Prioritization Enhancements for IIoT/URLLC Ericsson
R1-2106700 Discussion on intra-UE multiplexing/prioritization Spreadtrum Communications
R1-2106737 Discussion on enhanced intra-UE multiplexing ZTE
R1-2106804 Considerations on UL Intra-UE Multiplexing Sony
R1-2106838 Discussion on Intra-UE Multiplexing/Prioritization Quectel, Langbo
R1-2106882 Uplink intra-UE multiplexing and prioritization Samsung
R1-2106965 Intra-UE multiplexing and prioritization CATT
R1-2107073 Intra-UE multiplexing and prioritization InterDigital, Inc.
R1-2107115 Discussion on Intra-UE multiplexing of different priority Panasonic Corporation
R1-2107132 Discussion on intra-UE multiplexing and prioritization China Telecom
R1-2107157 Discussion on Intra-UE prioritization and multiplexing NEC
R1-2107181 Intra-UE multiplexing enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2107200 Discussion on Intra-UE Multiplexing and Prioritization Potevio Company Limited
R1-2107275 Enhancements on intra-UE multiplexing/prioritization OPPO
R1-2107295 Discussion on Intra-UE multiplexing/prioritization FGI, Asia Pacific Telecom
R1-2107339 Intra-UE multiplexing and prioritization for IOT and URLLC Qualcomm Incorporated
R1-2107446 Discussion on Intra-UE multiplexing/prioritization LG Electronics
R1-2107474 Intra-UE Multiplexing/Prioritization ETRI
R1-2107494 Methods for intra-UE multiplexing and prioritization MediaTek Inc.
R1-2107586 Further details of intra-UE uplink channel multiplexing and prioritization Intel Corporation
R1-2107735 Design considerations on Rel-17 intra-UE multiplexing/prioritization Apple
R1-2107793 Enhancements of intra-UE UCI multiplexing on PUCCH and PUSCH Sharp
R1-2107834 Intra-UE multiplexing/prioritization TCL Communication Ltd.
R1-2107854 Discussion on intra-UE multiplexing/prioritization for Rel.17 URLLC NTT DOCOMO, INC.
R1-2108013 Discussion on intra-UE multiplexing ITRI
R1-2108154 Discussion on intra-UE multiplexing/prioritization for URLLC/IIoT WILUS Inc.
[106-e-NR-R17-IIoT-URLLC-04] – Jia (OPPO)
Email discussion on intra-UE multiplexing/prioritization
- 1st check point: August 19
- 2nd check point: August 25
- 3rd check point: August 27
R1-2108274 Summary#1 of email thread [106-e-NR-R17-IIoT-URLLC-04] Moderator (OPPO)
Agreement
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a PUCCH in R17,
· HP A/N reuses rate matching equation, and RE mapping rules in Rel-15 for A/N+CSI-1.
· LP A/N reuses rate matching equation, and RE mapping rules in Rel-15 for CSI-2.
Above applies at least for PUCCH format 3 and 4.
Agreement
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a PUCCH in R17, an additional maxCodeRate for LP HARQ-ACK can be configured in the second PUCCH-Config per PUCCH format.
R1-2108336 Summary#2 of email thread [106-e-NR-R17-IIoT-URLLC-04] Moderator (OPPO)
Decision: As per email decision posted on Aug 25th,
Conclusion
Simultaneous PUCCH/PUSCH transmission on the same cell is not supported in Rel-17.
R1-2108402 Summary#3 of email thread [106-e-NR-R17-IIoT-URLLC-04] Moderator (OPPO)
Agreement
In NR Rel-17, [at least] 2 new set of beta offset values can be configured to the UE to indicate separate beta_offset values for the following cases:
· Multiplexing LP HARQ-ACK on HP PUSCH
· Multiplexing HP HARQ-ACK on LP PUSCH
R1-2108556 Summary#4 of email thread [106-e-NR-R17-IIoT-URLLC-04] Moderator (OPPO)
Working Assumption
For handling overlapping PUCCHs/PUSCHs with different priorities in R17
· Step 1: Resolve overlapping PUCCHs and/or PUSCHs with the same priority
· Step 2: Resolve overlapping PUCCHs and/or PUSCHs with different priorities
Note: Avoid recursive pseudo-code to implement this procedure
Note: It is expected that Rel-15 intra-UE UCI multiplexing timeline will be applicable
Decision: As per email decision posted on Aug 28th,
Agreement
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a PUCCH in R17,
· PUCCH resource set determination is based on: UCI payload size = the number of HP UCI bits + the number of LP UCI bits.
· FFS PRB number determination for HP A/N and LP A/N, e.g. based on their coding rates.
· FFS the impact to the number of LP UCI bits due to missed DCI and potential solutions
· Note: the number of LP UCI bits in the above agreement does may not necessarily mean the actual number of LP UCI bits until the second FFS is resolved
Final summary in R1-2108628
Including any RAN1 involvement in propagation delay compensation enhancements (including mobility issues, if any).
R1-2106590 Discussion on propagation delay compensation enhancements vivo
R1-2106638 Discussion on enhancements for propagation delay compensation Nokia, Nokia Shanghai Bell
R1-2106682 Propagation Delay Compensation Enhancements for Time Synchronization Ericsson
R1-2106738 Discussion on propagation delay compensation enhancements ZTE
R1-2106883 Discussion for propagation delay compensation enhancements Samsung
R1-2106966 Discussion on propagation delay compensation enhancements CATT
R1-2107276 Enhancement for support of time synchronization OPPO
R1-2107340 Enhancements for support of time synchronization for enhanced IIoT and URLLC Qualcomm Incorporated
R1-2107447 Discussion on propagation delay compensation enhancements LG Electronics
R1-2107495 Discussion on propagation delay compensation for time synchronization MediaTek Inc.
R1-2107587 Further analysis and design considerations for propagation delay compensation methods Intel Corporation
R1-2107678 Enhancements for support of time synchronization Huawei, HiSilicon
[106-e-NR-R17-IIoT-URLLC-05] – Chengyan (Huawei)
Email discussion on propagation delay compensation enhancements
- 1st check point: August 19
- 2nd check point: August 25
- 3rd check point: August 27
R1-2108200 Feature lead summary#1 on propagation delay compensation enhancements Moderator (Huawei)
R1-2108384 Feature lead summary#2 on propagation delay compensation enhancements Moderator (Huawei)
Agreement
SRS can be used for Rx – Tx time difference estimation at gNB side for RTT-based propagation delay compensation, if RTT-based propagation delay compensation is supported.
Agreement
Send LS to RAN4 to ask for feedback on the following questions:
· Question 1: Is it feasible to support a smaller value than the current Te for the use of propagation delay compensation, assuming the existing conditions in TS 38.133 for Te requirement? If not, is it feasible under new conditions (e.g. using TRS instead of SSB)? If the answer is yes, please also provide feedback on how much it can be reduced at most.
· Question 2: Is it feasible to introduce enhanced TA command indication granularity? If the answer is yes, please also provide feedback on how much it can be reduced at most (e.g. reduced to (1/16)* (16*64*Tc/2m)) similar as the granularity for Rel-16 IAB based on the Timing Delta MAC CE and related condition.
· Note 1: The alternatives in the working assumption achieved in RAN1#104bis-e together with the examples in Table 4.2-2 will be included in the LS to give some background for RAN4
· Note 2: The agreement “both SCS 15 kHz and 30 kHz are assumed for both control-to-control and smart grid for evaluation of the time synchronization” achieved in RAN1#102-e will be included in the LS for RAN4 information also.
· Note 3: Inform RAN4 that the enhancements on Te and TA command indication granularity for propagation delay compensation may or may not have impact on normal TA related procedure, depending on which candidate option for TA-based PDC is adopted. Note that this is just for RAN4 information.
· Note 4: Whether RAN1 will introduce specification enhancements is still undetermined.
R1-2108618 Draft LS on TA-based propagation delay compensation Moderator (Huawei)
Decision: Final LS is approved in R1-2108635.
Agreement
If RTT-based propagation delay compensation is supported,
· CSI-RS for tracking (TRS) can be used for Rx – Tx time difference estimation at UE side, if PRS is not configured for the UE.
· PRS can be used for Rx – Tx time difference estimation at UE side, if PRS is configured for the UE.
Send LS to RAN4 to ask for defining the following for RTT-based propagation delay compensation, if RTT-based propagation delay compensation is supported.
· UE Rx-Tx time difference measurement accuracy errorUE,RxTxDiff based on CSI-RS for tracking
· gNB Rx-Tx time difference absolute accuracy errorUE,RxTxDiff based on SRS
LS to RAN4 is postponed till the decision on whether to support RTT-based PDC or not.
R1-2108513 Feature lead summary#3 on propagation delay compensation enhancements Moderator (Huawei)
Agreement
Support the following configurations for RTT-based propagation delay compensation, if RTT-based propagation delay compensation is supported.
· At least one CSI-RS for tracking (TRS) configuration for Rx – Tx time difference estimation at UE side if PRS is not configured
· At least one SRS configuration for Rx – Tx time difference estimation at gNB side
Agreement
If RTT-based propagation delay compensation is supported and performed at the UE side, the Rx-Tx measurement report provided from the gNB to the UE should include at least:
· gNB Rx-Tx time difference at a given granularity
· FFS whether to include SRS-Resource-ID
Agreement
Take the following two alternatives as the equation for evaluation of the overall time synchronization error for RTT-based propagation delay compensation. RAN1 to select one of the alternatives in RAN1#106bis-e.
· Alt. 1:
o
is to reflect the error due to indication granularity of Rx-Tx time
difference
and 
reflects the measurement inaccuracy of gNB
Rx-Tx time difference, and the measurement inaccuracy of UE Rx-Tx time
difference, respectively.
o Note: The equation may be updated after clarification on the gNB TX-RX timing difference and UE TX-RX timing difference
· Alt. 2:
o
is to reflect the error due to indication granularity of Rx-Tx time
difference
o Note: Alt.2 assumes that gNB can coordinate the time of TA procedure and the time of PD compensation, so that the DL frame timing error and BS transmit timing error for propagation delay estimation is correlated to (e.g. the same as) that for the transmission of RRC signaling carrying the reference time clock
Note: FFS whether / how to handle inconsistent RTT measurement in gNB and UE due a change of uplink TX timing
R1-2108634 Final feature lead summary on propagation delay compensation enhancements Moderator (Huawei)
Please refer to RP-210854 for detailed scope of the WI.
Please also refer to section 5 of RP-212605 for additional guidance for this e-meeting.
[106bis-e-R17-RRC-IIoT-URLLC] – Klaus (Nokia)
Email discussion on Rel-17 RRC parameters for IIoT and URLLC
- 1st check point: October 14
- Final check point: October 19
R1-2110563 Summary of [106bis-e-R17-RRC-IIoT-URLLC] Email discussion on Rel-17 RRC parameters for IIoT and URLLC Moderator (Nokia)
Document is noted. For consolidation under 8 in [106bis-e-R17-RRC].
R1-2110670 List of agreements of Rel-17 URLLC/IIoT WI (post RAN1#106bis-e) WI rapporteur (Nokia)
R1-2108726 UE feedback enhancements for HARQ-ACK Huawei, HiSilicon
R1-2108829 HARQ-ACK Enhancements for IIoT/URLLC Ericsson
R1-2108840 Discussion on HARQ-ACK enhancements for eURLLC ZTE
R1-2108906 Discussion on HARQ-ACK feedback enhancements for Rel-17 URLLC Spreadtrum Communications
R1-2108966 HARQ-ACK enhancements for Rel-17 URLLC vivo
R1-2109093 HARQ-ACK enhancements for Rel-17 URLLC/IIoT OPPO
R1-2109131 UE feedback enhancements for HARQ-ACK NEC
R1-2109159 HARQ-ACK Feedback Enhancements for URLLC/IIoT Nokia, Nokia Shanghai Bell
R1-2109215 UE feedback enhancements for HARQ-ACK CATT
R1-2109256 Discussion on some remaining issues for UE HARQ-ACK feedback enhancements China Telecom
R1-2109277 Discussion on UE feeback enhancements for HARQ-ACK CMCC
R1-2109342 UE feedback enhancements for HARQ-ACK CAICT
R1-2109354 UE feedback enhancements for HARQ-ACK TCL Communication Ltd.
R1-2109406 UE feedback enhancements for HARQ-ACK Xiaomi
R1-2109482 On HARQ-ACK reporting enhancements Samsung
R1-2109575 On UE feedback enhancements for HARQ-ACK MediaTek Inc.
R1-2109604 Remaining issues of enhanced HARQ-ACK feedback procedures Intel Corporation
R1-2109671 Discussion on HARQ-ACK feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
R1-2109782 Considerations on HARQ-ACK enhancements for URLLC Sony
R1-2109809 UE feedback enhancements for HARQ-ACK ETRI
R1-2109821 Discussion on UE feedback enhancements for HARQ-ACK Panasonic
R1-2109822 Discussion on UE feedback enhancements for HARQ-ACK FGI, Asia Pacific Telecom
R1-2109893 HARQ enhancements for IIoT and URLLC InterDigital, Inc.
R1-2109940 HARQ-ACK feedback enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2109970 Discussion on UE feedback enhancement for HARQ-ACK LG Electronics
R1-2110027 Rel-17 URLLC UE feedback enhancements for HARQ-ACK Apple
R1-2110178 HARQ-ACK enhancement for IOT and URLLC Qualcomm Incorporated
R1-2110244 On the UE feedback enhancements for HARQ-ACK ITRI
R1-2110287 Discussion on PUCCH carrier switch for HARQ-ACK enhancement ASUSTeK
[106bis-e-NR-R17-IIoT-URLLC-01] – Klaus (Nokia)
Email discussion on UE feedback enhancements for HARQ-ACK
- 1st check point: October 14
- Final check point: October 19
R1-2109162 Moderator summary #1 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
From Oct 11th GTW session
Agreement
For PUCCH carrier switching, support PUCCH carrier switching only among different TDD cells with PUCCH configured on the NUL carrier in Rel-17.
Agreement
For semi-static PUCCH cell switching, PCell / PSCell / PUCCH-SCell is reference cell:
· The time domain pattern configurations are based on the numerology of the reference cell.
· The PDSCH to HARQ-ACK offset k1 is interpreted based on the numerology and PUCCH configuration of a reference cell to be able to apply the time-domain PUCCH cell switching pattern.
· Note: There may not be a need to define a ‘reference cell’ in the specification. This terminology is used for further clarifications of the procedure.
Decision: As per email decision posted on Oct 12th,
Agreement
For PUCCH cell switching, support independent TPC per PUCCH cell including
Agreement
UE does not expect overlapping PUCCH slots with dynamic PUCCH cell indication on more than one cell, i.e., gNB should only dynamically indicate a single PUCCH cell for a final PUCCH slot.
Agreement
For semi-static PUCCH cell switching, the time-domain pattern configuration is based on the following properties:
Agreement
For semi-static PUCCH cell switching, the PUCCH resource indicator (PRI) is interpreted based on the PUCCH configuration of determined target PUCCH cell.
Decision: As per email decision posted on Oct 14th,
Conclusion
For SPS HARQ-ACK deferral, only SPS HARQ-ACK bits subject to deferral from one or more initial slots which have not reached the maximum deferral value are jointly deferred to the next available PUCCH (other SPS HARQ-ACK is dropped).
Agreement
For SPS HARQ-ACK deferral, the bit ordering of deferred SPS HARQ-ACK information from one or more initial slots in the target PUCCH slot is based on the Rel.16 SPS HARQ-ACK bit order principle as in clause 9.1.2 of TS38.213 is applied, i.e., based on serving cell index, SPS configuration index, SPS PDSCH slot index.
Conclusion
No additional enhanced Type 3 CB ‘types’ (such as activated CCs, of specific SPS configurations, etc.) in terms of RRC configuration are supported.
Agreement
For one enhanced Type 3 HARQ-ACK CB, the same CBG and NDI configuration applies to both PHY priorities following the RAN1#106-e agreement.
Agreement
The same set of enhanced Type 3 CBs (incl. CBG and NDI configuration) is applied for triggering using DCI format 1_1 and 1_2.
Agreement
Reuse the legacy 1-bit ‘one-shot HARQ-ACK request’ for triggering indication of the enhanced Type 3 HARQ-ACK CB of smaller size.
· At least if only a single enhanced Type 3 HARQ-ACK CB is configured, the triggering DCI with the triggering bit set to ‘1’ is also able to schedule PDSCH.
Agreement
Support triggering of one-shot HARQ re-transmission on PUCCH using DCI format 1_2.
Agreement
To align with Rel-16 slot-based PUCCH repetition operation, support sub-slot based PUCCH repetition configured with / using nrofSlots (i.e., not using dynamic indication) of all UCI types (incl. HARQ, SR & CSI).
Agreement
For sub-slot based PUCCH repetition, the following agreement from Cov. Enh. WI for slot-based PUCCH repetition is adopted also for sub-slot based PUCCH repetition:
Agreement
o for a PUCCH resource, if both a new repetition parameter corresponding to Rel-17 dynamic PUCCH repetition factor indication and the Rel-15/16 nrofSlots are configured, the new repetition parameter overrides nrofSlots.
Agreement
For sub-slot based PUCCH repetition, the following agreement from Cov. Enh. WI for slot-based PUCCH repetition is adopted also for sub-slot based PUCCH repetition:
Agreement: Dynamic PUCCH repetition factor indication for SR or P/SP-CSI on PUCCH is not supported in Rel-17.
Agreement
For PUCCH cell switching based on dynamic indication in the DCI, introduce a new, dedicated DCI field for the DCI scheduling PDSCH to indicate the target PUCCH cell.
Agreement
In addition, the dynamic target PUCCH cell indication also applies to HARQ-ACK corresponding to SCell dormancy indication without scheduling PDSCH.
Agreement
The periodicity / length of the time-domain pattern for semi-static PUCCH cell switching is directly determined by the RRC configuration of the time domain pattern pucchCellPattern
· Note: pucchCellPattern has a variable length of (1… maxNrofSlots)
Agreement
For semi-static and dynamic indication of PUCCH cell switching, the PUCCH repetition factor is determined based on the PUCCH format or PUCCH resource on the target PUCCH cell for the first repetition.
R1-2110527 Moderator summary #2 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
From Oct 15th GTW session
Agreement
For Type-1 HARQ-ACK codebook for sub-slot based PUCCH configuration in Rel-17, the TDRA pruning/grouping is performed per DL slot after TDRA determination per sub-slot.
· Strive to minimize the impact on relevant pseudo-code
Conclusion
For SPS HARQ-ACK deferral, the operation in the ‘initial’ slot is further clarified as:
The UE performs first the (Rel-16) UCI multiplexing operation. If after the UCI multiplexing operation into a PUCCH or PUSCH if any, and if the UE would be transmitting SPS HARQ-ACK using the PUCCH SPS-PUCCH-AN-List-r16 or n1PUCCH-AN which is not valid, the SPS HARQ-ACK configured for deferral is deferred.
Agreement
The maximum number of simultaneously configurable enhanced Type 3 CB is indicated by the UE through UE capability signaling from the set of {1,2,4,8}.
Agreement
· PUCCH cell switching between 2 cells is supported in Rel-17.
Decision: As per email decision posted on Oct 18th,
Agreement
The CBG and NDI usage can be independently configured for different enhanced Type 3 HARQ-ACK CBs.
R1-2110561 Moderator summary #3 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
From Oct 18th GTW session
Agreement
For PUCCH repetition enhancements:
· Support inter-slotFrequencyHopping for PUCCH repetition operation of PUCCH Format 0 and Format 2 for slot-based PUCCH configurations.
· Support inter-subslot Frequency Hopping for PUCCH repetition operation of PUCCH Formats 0, 1, 2, 3 and 4 for 7OS slot-based PUCCH configurations.
o The UE applies the inter-subslot FH operation from sub-slot to sub-slot, if configured with inter-slotFrequencyHopping in the respective PUCCH_config.
· (Working Assumption) Support inter-subslot Frequency Hopping for PUCCH repetition operation of PUCCH Format 0 and Format 2 for 2OS slot-based PUCCH configurations.
o The UE applies the inter-subslot FH operation from sub-slot to sub-slot, if configured with inter-slotFrequencyHopping in the respective PUCCH_config.
· Note: As for Rel-15, the configuration / enabling of inter-slotFrequencyHopping and intraSlotFrequencyHopping is not supported.
Agreement
For sub-slot based PUCCH repetition, the following agreement from Cov. Enh. WI for slot-based PUCCH repetition is adopted also for sub-slot based PUCCH repetition:
Agreement
· In Rel-17, reuse the Rel-16 PUCCH repetition factors 2, 4, 8.
· Do not support PUCCH repetition factor larger than 8 In Rel-17.
Agreement
The RAN1#106-e agreement on the target slot definition is updated as follows:
Agreement (from RAN1#106-e)
For SPS HARQ-ACK
deferral, the target PUCCH slot is defined as the next
PUCCH slot, where after
performing the (Rel-16) UCI multiplexing operation into a PUCCH or PUSCH if
any, the UE would be either (i) transmitting HARQ-ACK using a PUCCH/PUSCH
other than the PUCCH determined from PUCCH SPS-PUCCH-AN-List-r16 or n1PUCCH-AN
or (ii) would be transmitting HARQ-ACK using a PUCCH resource configured in PUCCH
SPS-PUCCH-AN-List-r16 or n1PUCCH-AN being regarded as valid. sps-PUCCH-AN-List-r16 or n1PUCCH-AN PUCCH
resource is regarded as valid, or a PUCCH resource (from
PUCCH-ResourceSet, i.e. DG PDSCH HARQ multiplexed) is dynamically
indicated
· The target PUCCH slot determination is based on the total HARQ-ACK payload size including deferred SPS HARQ-ACK information and non-deferred HARQ-ACK information (if any) of a candidate target PUCCH slot
· The final PUCCH resource selection in the target PUCCH slot in terms of PUCCH resource set and PUCCH resource ID follows the Rel-16 procedures.
Agreement
Support PUCCH cell switching based on dynamic indication in the DCI using DCI format 1_2 for a UE supporting DCI format 1_2.
· The presence of the ‘PUCCH carrier switching’ bitfield in DCI format 1_2 is RRC configured.
Decision: As per email decision posted on Oct 20th,
Conclusion
If the UE is not configured with Rel-17 Intra-UE multiplexing, SPS HARQ for deferral of different PHY priorities can be separately deferred with the target PUCCHs separately determinate according to their respective PHY priorities.
· FFS on the PHY priority handling for SPS HARQ deferral if the UE configured with Rel-17 Intra-UE multiplexing
Agreement
For one-shot HARQ re-transmission on PUCCH, the triggering DCI dynamically indicates a ‘HARQ re-tx offset’ which is used to define the offset in number of PUCCH slots/sub-slots between the triggering DCI and the PUCCH slot/sub-slot of the HARQ-ACK codebook to be re-transmitted. For the triggering DCI received in slot/sub-slot m, indicating the HARQ-ACK re-tx in slot/sub-slot m+k and indicating HARQ_retx_offset, the PUCCH slot/sub-slot n of the HARQ-ACK codebook to be re-transmitted is determined as either:
· Alt. 1: n = m - HARQ_retx_offset
· Alt. 2: n = m + k - HARQ_retx_offset
· FFS: value range of the HARQ-retx_offset
Agreement
Down-select in RAN1#107-e from Alt. 1 & Alt. 3 below:
For PUCCH carrier switching based on semi-static operation, for the case the PCell slot to be longer than the target PUCCH cell slot or sub-slot (i.e. multiple target PUCCH cell slots overlapping with a single PCell slot), the following PUCCH cell slot is used for UCI transmission:
· Alt. 1: the first target PUCCH slot overlapping with the PCell slot
· Alt. 3: using a relative slot-offset within the reference cell slot, the relative slot offset is configured in the time domain pattern (i.e. time domain pattern contains ‘cell index’ & ‘slot_offset’ for each reference cell slot)
o Note: different relative slot offset can be configured for each reference cell slot in the time domain pattern, details see R1-2108829
Agreement
Down-select in RAN1#107-e from Alt. 2 & Alt. 4 below:
For PUCCH carrier switching based on semi-static operation, for the case the PCell slot to be shorter than the target PUCCH cell slot,
· Alt. 2: the UE does not expect the same UCI type (i.e. HARQ-ACK, SR or CSI) from more than one PCell PUCCH slot to be overlapping with a single dynamically indicated PUCCH cell slot
o Note: there can be e.g. HARQ-ACK only be present in either of the overlapping slots, but not in more than one overlapping slot.
· Alt. 4: the UE does not expect a semi-static PUCC cell configuration, where a single target PUCCH slot / sub-slot would be overlapping with more than one PCell slot/sub-slot.
Conclusion
There is no consensus to support multiplexing of HARQ-ACK (without dynamic PUCCH cell indication), SR and P/SP-CSI on the dynamically indicated PUCCH cell (other than PCell / PSCell / PUCCH-SCell) in Rel-17.
· FFS: further handling, incl. e.g., UE does not expect overlapping HARQ-ACK (without dynamic PUCCH cell indication), SR and P/SP-CSI or overlapping HARQ-ACK (without dynamic PUCCH cell indication), SR and P/SP-CSI is to be dropped
· FFS: overlapping definition for SR and P/SP-CSI in terms of PUCCH slot or PUCCH resource
Agreement
For one-shot triggering of HARQ-ACK re-transmission on PUCCH,
· in case the dynamic Type 2 HARQ-ACK codebook is configured, the HARQ-ACK codebook per PHY priority on the indicated PUCCH is constructed by appending the Type 2 HARQ-ACK codebook to be re-transmitted to the Type 2 HARQ-ACK codebook of the indicated PUCCH (carrying new, initial HARQ-ACK information) per PHY priority.
· in case the semi-static Type 1 HARQ-ACK codebook is configured, the HARQ-ACK codebook per PHY priority on the indicated PUCCH is constructed by appending the Type 1 HARQ-ACK codebook to be re-transmitted to the Type 1 HARQ-ACK codebook of the indicated PUCCH (carrying new, initial HARQ-ACK information) per PHY priority.
Final summary in R1-2110562.
R1-2108727 CSI feedback enhancements Huawei, HiSilicon
R1-2108830 CSI Feedback Enhancements for IIoT/URLLC Ericsson
R1-2110395 Discussion on CSI feedback enhancements for eURLLC ZTE (rev of R1-2108841)
R1-2108967 CSI feedback enhancements for Rel-17 URLLC vivo
R1-2109094 CSI feedback enhancements for URLLC OPPO
R1-2109216 CSI feedback enhancements CATT
R1-2109259 Discussion on CSI Feedback Enhancements Quectel, Langbo
R1-2109278 Discussion on CSI feeback enhancements for URLLC CMCC
R1-2109605 Remaining issues of enhanced sub-band CQI indication granularity Intel Corporation
R1-2109672 Discussion on CSI feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
R1-2109729 CSI feedback enhancements InterDigital, Inc.
R1-2109783 Remaining issues in 4 bits sub-band CQI reporting Sony
R1-2109941 CSI feedback enhancements for URLLC/IIoT Lenovo, Motorola Mobility
R1-2109971 Discussion on CSI feedback enhancements for URLLC LG Electronics
R1-2110028 Rel-17 URLLC UE feedback enhancement for CSI Apple
R1-2110179 CSI enhancement for IOT and URLLC Qualcomm Incorporated
R1-2110303 CSI feedback enhancements for URLLC/IIoT use cases Nokia, Nokia Shanghai Bell
R1-2109910 Feature lead summary#1 on CSI feedback enhancements for enhanced URLLC/IIoT InterDigital, Inc.
[106bis-e-NR-R17-IIoT-URLLC-02] – Paul (InterDigital)
Email discussion on CSI feedback enhancement
- 1st check point: October 14
- Final check point: October 19
R1-2110509 Feature lead summary#2 on CSI feedback enhancements for enhanced URLLC/IIoT Moderator (InterDigital, Inc.)
From Oct 15th GTW session
Agreement
· When subband CQI reporting is configured with 4-bits per subband, UE includes wideband CQI in report.
Final summary in R1-2110551.
R1-2108729 Uplink enhancements for URLLC in unlicensed controlled environments Huawei, HiSilicon
R1-2108788 UE initiated COT for semi-static channel access FUTUREWEI
R1-2108831 Enhancements for IIoT/URLLC on Unlicensed Band Ericsson
R1-2110396 Discussion on unlicensed band URLLC/IIoT ZTE (rev of R1-2108842)
R1-2108907 Discussion on enhancements for unlicensed band URLLCIIoT Spreadtrum Communications
R1-2108968 Enhancements for unlicensed band URLLC/IIoT vivo
R1-2109095 Enhancements for unlicensed band URLLC/IIoT OPPO
R1-2109138 UL enhancements for IIoT/URLLC in unlicensed controlled environment Nokia, Nokia Shanghai Bell
R1-2109217 Discussion on remaining issues on enhancements for unlicensed band URLLC/IIoT CATT
R1-2109356 Enhancements for unlicensed band URLLC/IIoT NEC
R1-2109407 Enhancement for unlicensed band URLLC IIoT Xiaomi
R1-2109453 Enhancements for unlicensed band URLLC/IIoT Panasonic Corporation
R1-2109483 Enhancements for unlicensed band URLLC/IIoT Samsung
R1-2109576 On the enhancements for unlicensed band URLLC/IIoT MediaTek Inc.
R1-2109606 Further Details for Enabling URLLC/IIOT in Unlicensed Band Intel Corporation
R1-2109673 Discussion on enhancements for unlicensed band URLLC NTT DOCOMO, INC.
R1-2109784 Considerations on unlicensed URLLC Sony
R1-2109810 Enhancements for unlicensed band URLLC/IIoT ETRI
R1-2109894 Enhancements for unlicensed band URLLC/IIoT InterDigital, Inc.
R1-2109942 Enhancements for unlicensed band URLLC/IIoT Lenovo, Motorola Mobility
R1-2109972 Discussion on unlicensed band URLLC/IIOT LG Electronics
R1-2109994 Enhancements for unlicensed band URLLC/IIoT Sharp
R1-2110029 URLLC uplink enhancements for unlicensed spectrum Apple
R1-2110180 Uplink enhancements for URLLC in unlicensed controlled environments Qualcomm Incorporated
R1-2110323 Discussion on enhancement for unlicensed URLLC/IIoT WILUS Inc.
[106bis-e-NR-R17-IIoT-URLLC-03] – Sorour (Ericsson)
Email discussion on unlicensed band URLLC/IIoT
- 1st check point: October 14
- Final check point: October 19
R1-2110423 Summary#1 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
R1-2110424 Summary#2 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
From Oct 13th GTW session
Possible agreement
In semi-static channel access mode, for PUSCH repetition Type B:
· Alt 2: If a nominal repetition overlaps with a set of symbols in an idle period associated to gNB’s FFP in case UE shares gNB-initiated COT for the nominal repetition or associated to UE’s FFP in case UE assumes UE-initiated COT for the nominal repetition, all the symbols in the idle period should be considered as invalid symbols which are not considered for an actual repetition as in Rel-16.
o Segmentation before and/or after the idle period is applied when applicable.
Chair’s recommendation: Try to use Alt-2 as baseline to achieve consensus.
Agreement
In semi-static channel access mode, for PUSCH repetition Type B, orphan symbol(s) are dropped as in Rel-16
Proposal 3-1 (updated): Select one of the following alternatives:
· Alt-A: In semi-static channel access mode, a DL transmission burst based on sharing of a UE initiated COT corresponding to a UE FFP, shall include only scheduled DL transmission or a DCI intended for the UE that initiated that FFP.
· Alt-B: In semi-static channel access mode, a DL transmission burst based on sharing of a UE initiated COT corresponding to a UE FFP, shall include scheduled DL transmission or a DCI intended for the UE that initiated that FFP.
o A DL transmission to any other UE in the cell than the COT initiating UE and/or a broadcast transmission can be additionally included in the DL transmission burst if the gNB fulfills the follwong condition:
§ It is gNB responsibility to ensure that reception of “the DL transmission or the broadcast transmission” does not affect any channel access related assumptions at UE for any UL transmission.
· That means that the reception of “the DL transmission or the broadcast transmission” does not affect any channel access related procedures (i.e. COT-ownership assumption, initiating a COT or sharing or using an initiated COT, sensing, skipping transmission/reception due to idle period of an initiated COT, etc.) for any UL transmission scheduled or configured to UE.
Decision: As per email decision posted on Oct 14th,
Agreement (further
modified on Oct 15th – see below)
In semi-static channel access mode, a DL transmission burst based on sharing of a UE initiated COT corresponding to a UE FFP, shall include scheduled DL transmission or a DCI intended for the UE that initiated that FFP.
· A DL transmission to any other UE in the cell than the COT initiating UE and/or a broadcast transmission can be additionally included in the DL transmission burst if the gNB fulfills the following condition:
o It is gNB‘s responsibility to ensure that other UEs do not assume any transmission in the DL transmission burst detected by the UEs as gNB-initiated COT.
Agreement
In semi-static channel access mode, the configuration of energy detection threshold to perform sensing at UE is based on maxEnergyDetectionThreshold.
· That means that in semi-static channel access mode, configuration of ul-toDL-COT-SharingED-Threshold is not applicable.
o As the consequence, energy detection threshold to perform sensing at UE is based on maxEnergyDetectionThreshold if maxEnergyDetectionThreshold is configured. Otherwise (i.e., if maxEnergyDetectionThreshold is not configured), energy detection threshold to perform sensing at UE is based on the UE maximum transmit power.
Agreement
Support configuration of harq-ProcID-Offset2 for operation in unlicensed spectrum when the cg-RetransmissionTimer-r16 is not configured.
Agreement
The following RRC parameters are NOT needed when cg-RetransmissionTimer is configured for CG operation with shared spectrum channel access.
· pusch-RepTypeIndicator
· startingFromRV0
Agreement
The RRC parameter of phy-PriorityIndex is applicable for CG operation in unlicensed band.
Agreement
Introduce new RRC parameters ul-AccessConfigListDCI-0-2 and ul-AccessConfigListDCI-1-2 to support indication of CP extension, LBT type, and CAPC with DCI 0_2 and 1_2 with dynamic channel access.
Decision: As per email decision posted on Oct 15th,
Agreement
In semi-static channel access mode, a DL transmission burst based on sharing of a UE initiated COT corresponding to a UE FFP, shall include scheduled DL transmission or a DCI intended for the UE that initiated that FFP.
R1-2110425 Summary#3 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
R1-2110426 Summary#4 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
R1-2110427 Summary#5 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
From Oct 19th GTW session
Agreement
In semi-static channel access mode, for PUSCH repetition Type B: If a nominal repetition overlaps with a set of symbols in an idle period associated to gNB’s FFP in case UE shares gNB-initiated COT for the nominal repetition or associated to UE’s FFP in case UE assumes UE-initiated COT for the nominal repetition, all the symbols in the idle period should be considered as invalid symbols which are not considered for an actual repetition as in Rel-16.
Agreement
In semi-static channel access mode for a UE which is allowed to operate as an initiating device, CG-StartingOffsets is not applicable.
· Note: That is, CG-StaringOffsets is not applicable at all for a UE configured with UE FFP parameters (e.g. period, offset) regardless whether the UE would initiate its own COT or would share gNB’s COT.
Decision: As per email decision posted on Oct 20th,
Agreement
When performing Intra-UE multiplexing procedure, if a PUCCH with HARQ-ACK overlaps with a CG-PUSCH and the cg-RetransmissionTimer is configured:
· If the HARQ-ACK and the CG-PUSCH have the same priority and the CG-PUSCH is selected for HARQ-ACK multiplexing:
o If cg-UCI-Multiplexing is enabled for that CG-PUSCH, HARQ-ACK would be multiplexed in CG-PUSCH.
o Otherwise, CG-PUSCH would be dropped.
· If the HARQ-ACK and the CG-PUSCH have different priority and the CG-PUSCH is selected for HARQ-ACK multiplexing:
o If multiplexing HARQ-ACK on the CG-PUSCH with different priroity is not indicated,
§ The LP channel between PUCCH or CG-PUSCH would be dropped as in Rel-16.
o If multiplexing HARQ-ACK on the CG-PUSCH with different priroity is indicated,
§ If cg-UCI-Multiplexing is enabled for that CG-PUSCH, HARQ-ACK would be multiplexed in CG-PUSCH.
§ Otherwise, the LP channel would be dropped.
Final summary in R1-2110653.
R1-2108728 Intra-UE multiplexing enhancements Huawei, HiSilicon
R1-2108832 Intra-UE Multiplexing/Prioritization Enhancements for IIoT/URLLC Ericsson
R1-2108843 Discussion on enhanced intra-UE multiplexing ZTE
R1-2108908 Discussion on intra-UE multiplexing/prioritization Spreadtrum Communications
R1-2108969 Intra-UE Multiplexing/Prioritization for Rel-17 URLLC vivo
R1-2109096 Enhancements on intra-UE multiplexing/prioritization OPPO
R1-2109132 Discussion on Intra-UE prioritization and multiplexing NEC
R1-2109160 On UL intra-UE prioritization and multiplexing enhancements Nokia, Nokia Shanghai Bell
R1-2109218 Intra-UE multiplexing and prioritization CATT
R1-2109260 Discussion on Intra-UE Multiplexing/Prioritization Quectel, Langbo
R1-2109355 Intra-UE multiplexing and prioritization TCL Communication Ltd.
R1-2109408 Intra-UE multiplexing prioritization for URLLC IIoT Xiaomi
R1-2109454 Discussion on Intra-UE multiplexing of different priority Panasonic Corporation
R1-2109484 Uplink intra-UE multiplexing and prioritization Samsung
R1-2109577 Methods for intra-UE multiplexing and prioritization MediaTek Inc.
R1-2109607 Further details of intra-UE uplink channel multiplexing and prioritization Intel Corporation
R1-2109674 Discussion on intra-UE multiplexing/prioritization for Rel.17 URLLC NTT DOCOMO, INC.
R1-2109730 Intra-UE multiplexing and prioritization InterDigital, Inc.
R1-2109785 Considerations on intra-UE UL multiplexing Sony
R1-2109811 Intra-UE Multiplexing/Prioritization ETRI
R1-2109943 Intra-UE multiplexing enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2109973 Discussion on Intra-UE multiplexing/prioritization LG Electronics
R1-2109995 Enhancements of channel collision resolution and intra-UE UCI multiplexing on PUCCH and PUSCH Sharp
R1-2110416 Rel-17 URLLC intra-UE multiplexing/prioritization Apple (rev of R1-2110030)
R1-2110181 Intra-UE multiplexing and prioritization for IOT and URLLC Qualcomm Incorporated
R1-2110245 Discussion on intra-UE multiplexing and prioritization ITRI
R1-2110324 Discussion on intra-UE multiplexing/prioritization for URLLC/IIoT WILUS Inc.
R1-2110510 Further discussion on UCI multiplexing and power control in Rel-17 URLLC Apple
[106bis-e-NR-R17-IIoT-URLLC-04] – Jia (OPPO)
Email discussion on intra-UE multiplexing/prioritization
- 1st check point: October 14
- Final check point: October 19
R1-2110463 Summary#1 of email thread [106bis-e-NR-R17-IIoT-URLLC-04] Moderator (OPPO)
From Oct 11th GTW session
Agreement (further modified as shown in Oct 19th GTW session)
The following working assumption is
confirmed with revision in RED.
For handling overlapping PUCCHs/PUSCHs with different priorities in R17
· Step 1: Resolve overlapping PUCCHs and/or PUSCHs with the same priority
o
Reuse
existing procedure for low priority PUCCH / PUSCH and high priority PUCCH /
PUSCH separately
· Step 2: Resolve overlapping PUCCHs and/or PUSCHs with different priorities
Note: Avoid recursive pseudo-code to implement this procedure
Note: It is expected that Rel-15 intra-UE UCI multiplexing timeline will be applicable
Decision: As per email decision posted on Oct 15th,
Agreement
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a PUCCH in R17, in case the total number of LP and HP HARQ-ACK bits is 2:
R1-2110472 Summary#2 of email thread [106bis-e-NR-R17-IIoT-URLLC-04] Moderator (OPPO)
From Oct 15th GTW session
Agreement
For both the subslot-based PUCCH and slot-based PUCCH, if simultaneous PUCCH/PUSCH transmission is not enabled, reuse Rel-16 procedure for Step 1.
R1-2110547 Summary#3 of email thread [106bis-e-NR-R17-IIoT-URLLC-04] Moderator (OPPO)
From Oct 19th GTW session
Agreement
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a PUSCH in R17, if HP HARQ-ACK and LP HARQ-ACK would be transmitted on HP/LP PUSCH without CSI,
· HP HARQ-ACK and LP HARQ-ACK are separately encoded according to R15 TS 38.212 Clause 5.3.1 and Clause 5.3.3.
· Reuse R15 HARQ-ACK rate matching/puncturing and RE mapping for HP HARQ-ACK in principle. FFS details.
· For LP HARQ-ACK, reuse R15 Part 1 CSI rate matching and RE mapping.
Agreement
For determining the PUCCH resource to carry the multiplexed high-priority and low-priority HARQ-ACKs,
· The number of RBs for multiplexing HP HARQ-ACK and LP HARQ-ACK on a PUCCH format 3 is determined as following:
o
If 
, the minimum number of RBs is determined as the number of 
, satisfying 
and 
§
Note: 
is multiplied at both sides to avoid mismatch between gNB and UE
due to floating point operation. Editor to capture as suggested.
o Otherwise,
§
Alt1: the number of RBs is 
. FFS: Whether/How LP HARQ-ACK is dropped.
§ Alt2: the number of RBs is determined by HP ACK payload size. LP HARQ-ACK is fully dropped.
§ Other alternatives are not precluded.
o r_HP_UCI is maxCodeRate configured for HP bits and r_LP_UCI is maxCodeRate configured for LP bits in the second PUCCH-Config (the PUCCH-config containing the PUCCH resource of the HP HARQ-ACK).
§ FFS whether more than one maxCodeRate can be configured for one priority.
o
If 
is not equal to 
according to [4, TS 38.211], is increased to the nearest allowed value of nrofPRBs for PUCCH-format3
provided by the second PUCCH-Config [12, TS 38.331].
o HP coded bits and LP coded bits are not transmitted using the same RE(s)
· FFS for PUCCH format 2.
Agreement
For collision between HP CG PUSCH and LP DG PUSCH, if MAC delivers two MAC PDUs to PHY, PHY layer can make the prioritization so that the UE is expected to transmit the CG PUSCH and cancel the DG PUSCH at latest from the first symbol that is overlapping with the CG PUSCH.
· Note: For the DG PUSCH, it is up to UE implementation to handle OFDM symbols of the DG PUSCH before the start of HP CG PUSCH which are nonoverlapping with the HP CG PUSCH.
· FFS: How to handle the collision when there is repetition for CG and/or DG PUSCH
Final summary inR1-2110636.
Including any RAN1 involvement in propagation delay compensation enhancements (including mobility issues, if any).
R1-2108833 Propagation Delay Compensation Enhancements for Time Synchronization Ericsson
R1-2110397 Discussion on propagation delay compensation enhancements ZTE (rev of R1-2108844)
R1-2108970 Discussion on propagation delay compensation enhancements vivo
R1-2109097 Enhancement for support of time synchronization OPPO
R1-2109161 Discussion on enhancements for propagation delay compensation Nokia, Nokia Shanghai Bell
R1-2109219 Discussion on propagation delay compensation enhancements CATT
R1-2109485 Discussion for propagation delay compensation enhancements Samsung
R1-2109608 Remaining issues on propagation delay compensation Intel Corporation
R1-2109743 Enhancements for support of time synchronization Huawei, HiSilicon
R1-2109974 Discussion on propagation delay compensation enhancements LG Electronics
R1-2110182 Enhancements for support of time synchronization for enhanced IIoT and URLLC Qualcomm Incorporated
[106bis-e-NR-R17-IIoT-URLLC-05] – Chengyan (Huawei)
Email discussion on propagation delay compensation enhancements
- 1st check point: October 14
- Final check point: October 19
R1-2110473 Feature lead summary#1 on propagation delay compensation enhancements Moderator (Huawei)
From Oct 13th GTW session
For evaluation of the overall time synchronization error for RTT-based propagation delay compensation,
· Alt.1 for RTT-based PDC
Agreement
For evaluation of the overall time synchronization error for TA-based propagation delay compensation,
· Alt.1 for TA-based PDC
Agreement
For evaluation of the overall time synchronization error for RTT-based propagation delay compensation with Alt.1, it is assumed that
· The UE Rx-Tx time difference measurement accuracy based on PRS defined in Table 10.1.25.2-2 in TS 38.133 v17.3.0 is taken as the reference for the UE Rx-Tx time difference measurement accuracy
· The gNB Rx-Tx time difference accuracy based on SRS for positioning defined in Table 13.2.2.2-1 in TS 38.133 v17.3.0 is taken as the reference for the gNB Rx-Tx time difference accuracy based on SRS for PDC
Decision: As per email decision posted on Oct 14th,
Agreement
For RTT-based PDC, only a single pair of CSI-RS for tracking (TRS)/PRS and SRS configuration, i.e. one CSI-RS for tracking (TRS)/PRS configuration for Rx – Tx time difference estimation at UE side and one SRS configuration for Rx – Tx time difference estimation at gNB side, is configured for PDC in Rel-17, if RTT-based PDC is supported.
Agreement
If RTT-based propagation delay compensation is supported and performed at the gNB side, the Rx-Tx measurement report provided from the UE to the gNB should include at least:
· UE Rx-Tx time difference at a given granularity
Conclusion
When evaluating enhanced TA-based PDC, there is no need to replace Te by TA adjustment error.
R1-2110474 Feature lead summary#2 on propagation delay compensation enhancements Moderator (Huawei)
R1-2110558 Feature lead summary#3 on propagation delay compensation enhancements Moderator (Huawei)
From Oct 18th GTW session
Session opening with a birthday celebration:
R1-2110700 Happy Birthday Patrick RAN1
Noted. Thank you all for the so kind attention!!
Agreement
Send an LS to RAN2 and CC RAN4 with the content including:
· The latest available status on PDC methods in RAN1, e.g. key agreements achieved for TA-based PDC and RTT-based PDC.
On Oct 19th,
R1-2110594 Draft LS on propagation delay compensation Huawei
Decision: The draft LS is endorsed. Final version is approved in R1-2110647.
Agreement
For
evaluation and comparison of enhanced TA-based PDC and RTT-based PDC, the
timing detection error = 0.5/(RS BW) = 0.5/(N_PRB*12*SCS) can be used to
achieve 
and 
, if needed in the
evaluation equation separately, where N_PRB is the number of PRBs of the RS
bandwidth used in the detection by UE and gNB, respectively.
· Note: Detection error achieved by evaluations is not precluded if available.
R1-2110559 Feature lead summary#4 on propagation delay compensation enhancements Moderator (Huawei)
From Oct 19th GTW session
Agreement
If enhanced TA-based PDC with reduced Te based on TRS is supported in Rel-17, one CSI-RS for tracking (TRS) configuration is configured for enhanced TA-based PDC.
· FFS whether/how to configure UL signal for enhanced TA-based PDC
Agreement
If enhanced TA-based PDC with enhanced TA command indication granularity is supported in Rel-17,
· The enhanced TA command indication granularity introduced for enhanced PDC is applied for PDC purpose, which doesn’t have impact on normal TA procedure, i.e. normal TA procedure will still follow the existing TA command indication granularity.
Agreement
If RTT-based propagation delay compensation is supported, the Rx-Tx time difference is reported with granularity 2k*Tc, where k is an integer satisfying 0<=k<=5.
· FFS the value of k
· FFS the reporting range of Rx-Tx time difference measurement for PDC
Final summary in R1-2110651.
Please refer to RP-210854 for detailed scope of the WI.
Please also refer to section 5 of RP-212605 for additional guidance for this e-meeting.
Rel-17 CRs related to IIoT/URLLC
R1-2112429 Introduction of UE initiating a channel occupancy in semi-static channel access mode for enhanced IIoT and URLLC operation on shared spectrum for NR Ericsson
Decision: Draft CR to 37.213 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
R1-2112444 Introduction of IIoT/URLLC enhancements in NR Samsung
Decision: Draft CR to 38.213 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
R1-2112475 Introduction of Rel-17 enhanced IIoT and URLLC Huawei
Decision: Draft CR to 38.212 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
R1-2112484 Introduction of enhanced Industrial Internet of Things (IoT) and ultra-reliable and low latency communication (URLLC) support for NR Nokia
Decision: Draft CR to 38.214 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
R1-2112514 Introduction of IIoT/URLLC enhancements in NR Qualcomm
Decision: Draft CR to 38.202 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
[107-e-R17-RRC-IIoT-URLLC] – Klaus (Nokia)
Email discussion on Rel-17 RRC parameters for IIoT and URLLC
- Email discussion to start on November 15
R1-2112760 Summary of [107-e-R17-RRC-IIoT-URLLC] Email discussion on Rel-17 RRC parameters for IIoT and URLLC Moderator (Nokia)
Document is noted. For consolidation under 8 in [107-e-R17-RRC].
R1-2112761 List of agreements of Rel-17 URLLC/IIoT WI (post RAN1#107-e) WI rapporteur (Nokia)
R1-2110818 UE feedback enhancements for HARQ-ACK Huawei, HiSilicon
R1-2110914 Discussion on HARQ-ACK enhancements for eURLLC ZTE
R1-2111005 Remaining issues on HARQ-ACK enhancements for Rel-17 URLLC vivo
R1-2111094 Discussion on HARQ-ACK feedback enhancements for Rel-17 URLLC Spreadtrum Communications
R1-2111139 HARQ-ACK Feedback Enhancements for URLLC/IIoT Nokia, Nokia Shanghai Bell
R1-2111188 HARQ-ACK Enhancements for IIoT/URLLC Ericsson
R1-2111248 UE feedback enhancements for HARQ-ACK CATT
R1-2111341 HARQ-ACK enhancements for Rel-17 URLLC/IIoT OPPO
R1-2111390 Remaining issues in HARQ-ACK enhancements for URLLC Sony
R1-2111434 Discussion on PUCCH carrier switching for HARQ feedback enhancement China Telecom
R1-2111489 Remaining open issues of UE HARQ feedback enhancements Intel Corporation
R1-2111567 UE feedback enhancements for HARQ-ACK Xiaomi
R1-2111604 Discussion on UE feeback enhancements for HARQ-ACK CMCC
R1-2111678 Discussion on UE feedback enhancements for HARQ-ACK Panasonic
R1-2111704 UE feedback enhancements for HARQ-ACK NEC
R1-2111730 On HARQ-ACK reporting enhancements Samsung
R1-2111839 HARQ enhancements for IIoT and URLLC InterDigital, Inc.
R1-2111867 HARQ-ACK feedback enhancements for URLLC Apple
R1-2111942 HARQ-ACK feedback enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2111988 UE feedback enhancements for HARQ-ACK ETRI
R1-2112052 Discussion on UE feedback enhancement for HARQ-ACK LG Electronics
R1-2112076 Discussion on UE feedback enhancements for HARQ-ACK FGI, Asia Pacific Telecom
R1-2112081 UE feedback enhancements for HARQ-ACK TCL Communication Ltd.
R1-2112102 Discussion on HARQ-ACK feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
R1-2112173 On the UE feedback enhancements for HARQ-ACK ITRI
R1-2112209 HARQ-ACK enhancement for IOT and URLLC Qualcomm Incorporated
R1-2112285 On UE feedback enhancements for HARQ-ACK MediaTek Inc.
R1-2112395 UE feedback enhancements for HARQ-ACK for NR Rel-17 URLLC/IIoT CAICT
[107-e-NR-R17-IIoT-URLLC-01] – Klaus (Nokia)
Email discussion on UE feedback enhancements for HARQ-ACK
- 1st check point: November 15
- Final check point: November 19
Decision: As per email decision posted on Nov 12th,
Agreement
The maximum SPS HARQ-ACK deferral value in terms of k1+k1def per SPS configuration is RRC configured from a value range of {1…32}.
Agreement
The list enhanced Type 3 HARQ-ACK codebooks is configured per PUCCH cell group (i.e., separately configurable for primary and secondary PUCCH cell group).
Agreement
The one-shot HARQ re-transmission on PUCCH is configured per PUCCH cell group (i.e., separately configurable for primary and secondary PUCCH cell group).
Agreement
For one-shot HARQ re-transmission on PUCCH, the ‘HARQ re-tx offset’ is determined as Alt. 1: n = m - HARQ_retx_offset
Conclusion
There is no consensus to support the simultaneous configuration of one-shot HARQ-ACK re-transmission and dynamic PUCCH cell switching in Rel-17.
Conclusion
For SPS HARQ-ACK deferral, if a UE is not configured with Rel-17 intra-UE multiplexing but configured with Rel-16 PHY prioritization, the UE first performs Rel-16 UCI multiplexing and PHY prioritization in both initial slot and target slot and if a LP SPS HARQ-ACK PUCCH is deprioritized, the LP SPS HARQ-ACK is not deferred.
· Note: If the SPS HARQ-ACK is deprioritized in any slot, no further deferral.
Agreement
Support simultaneous configuration of SPS HARQ-ACK deferral and PUCCH cell switching based on the semi-static time domain pattern:
· For the target slot determination of SPS HARQ-ACK deferral,
o Step 1: the UE first determines a next PUCCH slot on the cell for PUCCH transmission using the semi-static time-domain PUCCH cell pattern and the related rules for semi-static PUCCH cell switching, followed by
o Step 2: the UE determines based on the SPS HARQ-ACK deferral rules if this PUCCH slot on the PUCCH cell for transmission is the target PUCCH slot or not.
o Note: In step 1, k is increased on PCell/PScell/PUCCH-Scell. “The next PUCCH slot” represents the slot on the PUCCH cell based on PUCCH cell pattern, which is mapped from the PCell/PScell/PUCCH-Scell slot with increased K1.
o Note: The maximum deferral limitation checking is based on the effective k + kdef value based on the granularity of PCell / PScell/PUSCCH-Scell
Agreement
Support simultaneous configuration of one-shot HARQ-ACK re-transmission and semi-static PUCCH cell switching:
· the ‘backward HARQ-ACK slot-offset’ is interpreted with the granularity of a PUCCH slot of the respective PHY priority of PCell /PSCell / PUCCH SCell
R1-2111142 Moderator summary #1 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
From Nov 12th GTW session
Agreement
Confirm the following RAN1 working assumption from RAN1#106bis-e with the additional agreement on UE capability (in RED):
|
· (Working Assumption) Support inter-subslot Frequency Hopping for PUCCH repetition operation of PUCCH Format 0 and Format 2 for 2OS slot-based PUCCH configurations. o The UE applies the inter-subslot FH operation from sub-slot to sub-slot, if configured with inter-slotFrequencyHopping in the respective PUCCH_config. |
· Support single UE capability indication of inter-subslot FH for PUCCH repetition operation.
Agreement
Apply a 1-bit triggering DCI field for triggering indication of one-shot HARQ re-transmission on PUCCH.
· The triggering DCI with the triggering bit set to ‘1’ is not able to schedule PDSCH.
· Some unused bit field in the DCI is used to indicate the HARQ slot offset.
· FFS: if the ‘one-shot HARQ-ACK request’ field can be reused
· FFS: which unused DCI field in the DCI is used for HARQ slot offset indication
· FFS: The indication of whether the PDSCH is not scheduled will reuse Rel-16 type-3 HARQ ACK CB UE behavior
Decision: As per email decision posted on Nov 17th,
Agreement
The earlier RAN1 agreements on the valid symbol definition in the initial and target PUCCH slot for SPS HARQ-ACK deferral are further clarified as:
· For SPS HARQ-ACK deferral, for the determination of valid symbols in the initial and target PUCCH slot/sub-slot a collision with semi-static DL symbols, SSB and symbols indicated by pdcch-ConfigSIB1 in MIB for a CORESET for Type0-PDCCH CSS set is regarded as ‘invalid’ or ‘no symbols for UL transmission’.
Conclusion:
There is no consensus to support the simultaneous configuration of the Rel-16 Type 3 HARQ-ACK CB and Rel-17 one-shot re-tx HARQ triggering for a UE in Rel-17 .
Conclusion:
There is no consensus to support the simultaneous configuration of the Rel-17 Enhanced Type 3 HARQ-ACK CB and Rel-17 one-shot HARQ re-tx triggering for a UE in Rel-17.
Agreement
Support simultaneous configuration of enhanced Type 3 CB triggering and PUCCH cell switching.
Conclusion:
For PUCCH cell switching DCI field size alignment is done by:
· For dynamic PUCCH cell switching, the bit width of the PDSCH-to-HARQ_feedback timing indicator in DCI format 1_1 and 1_2 is determined by the largest K1 set among the K1 sets of all candidate PUCCH cells for PUCCH cell switching based on dynamic indication
o i.e., a number of most significant bits with value set to '0' are inserted to smaller field until the bit width of the field for all the PUCCH cells are the same
o Note: for semi-static PUCCH cell switching only the K1 set of PCell is needed
· For semi-static and dynamic PUCCH cell switching, the bit width of the PRI field in DCI format 1_2 is determined by the largest value of numberOfBitsForPUCCH-ResourceIndicatorDCI-1-2 of all PUCCH cells
o i.e., a number of most significant bits with value set to '0' are inserted to smaller field until the bit width of the field for all the PUCCH cells are the same
· FFS: If similar handling is applied for ChannelAccess-CPext DCI field (0 or 2 bit)
Agreement
For PUCCH cell switching and a PUCCH transmission on the alternative PUCCH cell, the alternative PUCCH cell is used to derive the downlink pathloss estimate PLb,f,c(qd), i.e., replace in the main bullet of the PLb,f,c(qd) determination in Sec. 7.2.1 of 38.213 the ‘primary cell’ with ‘cell for PUCCH transmission’.
Agreement
For PUCCH cell switching based on semi-static operation, for the case the PCell slot to be longer than the target PUCCH cell slot or sub-slot (i.e., multiple target PUCCH cell slots overlapping with a single PCell slot), adopt Alt 1, i.e., the first target PUCCH slot overlapping with the PCell slot is used for UCI transmission.
Decision: As per email decision posted on Nov 18th,
Agreement
Support simultaneous configuration of Rel-16 Type 3 HARQ-ACK codebook or enhanced Type 3 HARQ-ACK codebook triggering and SPS HARQ-ACK deferral.
· In case a R16 Type 3 HARQ-ACK CB or an enhanced Type 3 HARQ-ACK codebook is triggered for transmission in a PUCCH slot, the UE stops the deferral procedure of pending SPS HARQ-ACK in that PUCCH slot and that PUCCH slot is not considered as a potential target slot for SPS HARQ-ACK deferral anymore.
Agreement
One enhanced Type 3 HARQ-ACK codebook is RRC configured either as:
· a subset of CC, i.e., all HARQ processes of the subset of CCs are part of the codebook, OR
|
pdsch-HARQ-ACK-enhType3perCC |
Configure the one enhanced Type 3 HARQ-ACK codebook using per CC configuration |
(1..maxNrofServingCells) of Integer (0,1) |
· a subset of configured HARQ processes per CC, i.e., different subsets of HARQ processes can be configured for each CC.
|
pdsch-HARQ-ACK-enhType3perHARQ |
Configure the one enhanced Type 3 HARQ-ACK codebook using a per HARQ process and CC configuration |
(1..maxNrofServingCells) of Bit String (Size (16)) |
Agreement
For one-shot triggering of HARQ re-transmission, introduce a new 1-bit DCI field in DCI format 1_1 and in DCI format 1_2 (if DCI format 1_2 is configured with one-shot triggering of HARQ-ACK re-transmission).
Agreement
The time-domain pattern for semi-static PUCCH cell switching is separately configurable for the primary and secondary PUCCH cell group.
Agreement
The
time-domain pattern for semi-static PUCCH cell switching is based on the
reference SCS configuration provided by tdd-UL-DL-ConfigurationCommon
and is common to each every configured UL BWP (of PCell / SPCell / PUCCH
SCell).
Agreement
For PUCCH cell switching based on semi-static operation, adopt Alt. 4, i.e., the UE does not expect a semi-static PUCCH cell configuration, where a single target PUCCH slot / sub-slot would be overlapping with more than one PCell slot/sub-slot.
Agreement
For semi-static PUCCH cell switching, if the alternative PUCCH cell (i.e. PUCCH sCell) is deactivated or the alternative PUCCH Cell is dormant, the UE does not apply time-domain pattern and the UCI is to be transmitted on PCell / SPCell / PUCCH SCell.
Conclusion
There is no consensus to support simultaneous configuration of semi-static PUCCH cell switching and dynamic PUCCH cell switching in Rel-17.
R1-2112616 Moderator summary #2 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
R1-2112757 Moderator summary #3 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
From Nov 19th GTW session
Working Assumption
For one-shot triggering of HARQ re-transmission, in addition to one-shot triggering of HARQ re-transmission after the initial PUCCH transmission slot, the triggering is supported before the initial PUCCH transmission slot
· Re-transmission triggering does not change processing for the initial PUCCH transmission (i.e., HARQ multiplexing / dropping / transmission)
· The UE expects the PUCCH carrying the HARQ-ACK re-transmission to be scheduled in a slot/sub-slot after the initial PUCCH transmission slot/sub-slot.
· The support for the triggering before the initial PUCCH transmission slot is subject to separate UE capability indication
Agreement
If more than one (M>1) enhanced Type 3 HARQ-ACK codebook is configured and the triggering DCI with the ‘one-shot HARQ-ACK request’ set to ‘1’,
· If the FDRA field is not valid, i.e. all “1s” or all “0s” as per Rel-16, then PDSCH is not scheduled:
o If a new field with N=ceiling(log2 (M)) bits is configured in the triggering DCI, the UE uses this new field to indicate one of M configured e-Type 3 HARQ-ACK CBs
o If the new field is not configured in the triggering DCI, the UE uses the MCS field to indicate one of M configured e-Type 3 HARQ-ACK CBs
· If the FDRA field is valid, then a PDSCH is scheduled
o If a new field with N=ceiling(log2 (M)) bits is configured in the triggering DCI, the UE uses this new field to indicate one of M configured e-Type 3 HARQ-ACK CBs
o If the new field is not configured in the triggering DCI, the UE selects the 1st indexed e-Type 3 HARQ-ACK CB in the M configured e-Type 3 HARQ-ACK CBs
Agreement
For one-shot HARQ-ACK re-transmission, the value range for HARQ re-tx offset is fixed in the specification.
Conclusion
For dynamic PUCCH cell switching, the UE does not expect a PUCCH slot with UCI on PCell /SPCell / PUCCH SCell to overlap with a PUCCH slot with HARQ-ACK on the dynamically indicated alternative PUCCH PUCCH cell.
· The UCI on PCell /SPCell / PUCCH SCell dropped due to collision with semi-static DL symbols, SSB, and symbols indicated by pdcch-ConfigSIB1 in MIB for a CORESET for Type0-PDCCH CSS set is exempted and is not multiplexed on the PUCCH on the alternative PUCCH cell.
Final summary in R1-2112758.
R1-2110820 Uplink enhancements for URLLC in unlicensed controlled environments Huawei, HiSilicon
R1-2110878 UE initiated COT for semi-static channel access FUTUREWEI
R1-2110915 Discussion on unlicensed band URLLC/IIoT ZTE
R1-2111006 Remaining issues on enhancements for unlicensed band URLLC/IIoT vivo
R1-2111095 Discussion on enhancements for unlicensed band URLLC/IIoT Spreadtrum Communications
R1-2111176 Enhancements for unlicensed band URLLC/IIoT NEC
R1-2111189 Enhancements for IIoT/URLLC on Unlicensed Band Ericsson
R1-2111249 Discussion on remaining issues on enhancements for unlicensed band URLLC/IIoT CATT
R1-2111342 Enhancements for unlicensed band URLLC/IIoT OPPO
R1-2111363 UL enhancements for IIoT/URLLC in unlicensed controlled environment Nokia, Nokia Shanghai Bell
R1-2111391 Remaining issues in Unlicensed URLLC Sony
R1-2111490 Remaining Details for Enabling URLLC/IIoT in Unlicensed Band Intel Corporation
R1-2111568 Enhancement for unlicensed band URLLC IIoT Xiaomi
R1-2111731 Enhancements for unlicensed band URLLC/IIoT Samsung
R1-2111840 Enhancements for unlicensed band URLLC/IIoT InterDigital, Inc.
R1-2111868 URLLC uplink enhancements for unlicensed spectrum Apple
R1-2111943 Enhancements for unlicensed band URLLC/IIoT Lenovo, Motorola Mobility
R1-2111989 Remaining issues on enhancements for unlicensed band URLLC/IIoT ETRI
R1-2112013 Enhancements for unlicensed band URLLC/IIoT Sharp
R1-2112053 Discussion on unlicensed band URLLC/IIOT LG Electronics
R1-2112210 Uplink enhancements for URLLC in unlicensed controlled environments Qualcomm Incorporated
R1-2112286 On the enhancements for unlicensed band URLLC/IIoT MediaTek Inc.
R1-2112386 Remaining issues on enhancement for unlicensed URLLC/IIoT WILUS Inc.
[107-e-NR-R17-IIoT-URLLC-02] – Sorour (Ericsson)
Email discussion on unlicensed band URLLC/IIoT
- 1st check point: November 15
- Final check point: November 19
R1-2112545 Summary#1 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
R1-2112546 Summary#2 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
From Nov 16th GTW session
Agreement:
In semi-static channel access mode, for a transmission burst that includes multiple transmissions, the associated COT-ownership for all transmissions in the transmission burst should be the same.
Agreement:
In semi-static channel access mode, when a UE is enabled to initiate a channel occupancy:
· If single DCI schedules multiple UL transmissions, the COT initiator assumption indicated by the single DCI is applied for all the UL transmissions scheduled by the single DCI.
Agreement:
In semi-static channel access mode, when a DCI schedules a UL transmission in the same g-FFP and the UL transmission is not aligned with a u-FFP boundary and the DCI indicates UE initiated COT, the following are applied:
· If the UE has initiated the COT in that u-FFP and satisfies the applicable sensing conditions, the UL transmission occurs. Otherwise, the UL transmission is dropped.
Agreement:
The following channel access procedures for consecutive scheduled UL transmissions are applicable to the semi-static channel access mode.
· If a UE is scheduled by a gNB to transmit a set of UL transmissions including PUSCH or SRS symbol(s) using a UL grant, the UE shall not apply a CP extension for the remaining UL transmissions in the set after the first UL transmission after accessing the channel.
· If a UE is scheduled to transmit a set of consecutive UL transmissions without gaps including PUSCH using one or more UL grant(s), PUCCH using one or more DL grant(s), or SRS with one or more DL grant(s) or UL grant(s) and the UE transmits one of the scheduled UL transmissions in the set after accessing the channel, the UE may continue transmission of the remaining UL transmissions in the set, if any.
· Note: The procedures above are based on description in Clause 4.2.1.0.1 of TS 37.213.
Agreement:
In semi-static channel access mode, when the gNB schedules by a DCI a UL transmission and the scheduling DCI and the scheduled UL transmission are in a same g-FFP but on a different RB sets of the g-FFP bandwidth:
· If DCI indicates gNB initiated COT, validation of the gNB-initiated COT (based on the detection of DL transmission from the gNB) for the RB sets with scheduled UL can be skipped.
Agreement:
The symbol offset for the UE FFP configuration is determined based on the smallest SCS among configured SCSs in a serving cell.
R1-2112547 Summary#3 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
R1-2112548 Summary#4 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
Decision: As per email decision posted on Nov 20th,
Conclusion
PUSCH repetition Type B for DG on unlicensed spectrum in Rel-17 is supported.
Conclusion
In semi-static channel access mode when a UE can operate as an initiating device, for a configured UL transmission, the required time to determine whether the configured UL transmission could correspond to gNB’s COT or UE’s COT is up to UE implementation.
Conclusion
In semi-static channel access mode when a UE can operate as an initiating device, for a scheduled UL transmission, when the scheduling DCI and the first symbol of the scheduled UL transmission are in the same g-FFP, the processing time for the scheduled UL transmission satisfies the time required to the UE determine whether the scheduled UL transmission could correspond to the COT initiator assumption indicated in the DCI.
Conclusion
In semi-static channel access mode when a UE can operate as an initiating device, for a scheduled UL transmission, when the scheduling DCI and the first symbol of the scheduled UL transmission are in different g-FFPs, and if the DCI indicates gNB as the COT initiator:
· the required time to determine whether the gNB had initiated a COT before the start of the scheduled UL transmission is up to UE implementation.
Agreement
For operation in a cell with shared spectrum access, a UE configured with multiple CG configurations does not expect to operate in the cell with more than one active CG configurations for which the cg-RetransmissionTimer is provided in one active CG configuration and not provided in another.
· Note: That means that the UE operates with a same CG type (i.e., Rel-16 NR-U CG type or Rel-16 URLLC CG type per previous agreements) per cell in a shared spectrum.
Agreement
EnableConfiguredUL is not applicable if cg-RetransmissionTimer is not configured in Rel-17.
Agreement
In semi-static channel access mode, when the cg-RetransmissionTimer-r16 is enabled and a UE operates as an initiating device, the RRC parameter cg-COT-SharingList-16 is reused, and the UE is not expected to provide any relevant information related to CAPC to the gNB.
· Channel Occupancy Time (COT) sharing information bit-field in CG-UCI is as the following:
o
bits if higher layer
parameter cg-COT-SharingList is configured, where C is the number of combinations configured in cg-COT-SharingList;
o 0 bit otherwise;
Final summary in R1-2112549.
R1-2110819 Intra-UE multiplexing enhancements Huawei, HiSilicon
R1-2110916 Discussion on enhanced intra-UE multiplexing ZTE
R1-2111007 Remaining issues on intra-UE Multiplexing/Prioritization for Rel-17 URLLC vivo
R1-2111096 Discussion on intra-UE multiplexing/prioritization Spreadtrum Communications
R1-2111140 On UL intra-UE prioritization and multiplexing enhancements Nokia, Nokia Shanghai Bell
R1-2111190 Intra-UE Multiplexing/Prioritization Enhancements for IIoT/URLLC Ericsson
R1-2111250 Intra-UE multiplexing and prioritization CATT
R1-2111343 Enhancements on intra-UE multiplexing/prioritization OPPO
R1-2111359 Discussion on Intra-UE Multiplexing/Prioritization Quectel, Langbo
R1-2111392 Remaining issues in Intra-UE UL Multiplexing Sony
R1-2111436 Discussion on Intra-UE multiplexing of different priority Panasonic Corporation
R1-2111491 Remaining open details of intra-UE uplink channel multiplexing and prioritization Intel Corporation
R1-2111569 Intra-UE multiplexing prioritization for URLLC IIoT Xiaomi
R1-2111705 Discussion on Intra-UE prioritization and multiplexing NEC
R1-2111732 Uplink intra-UE multiplexing and prioritization Samsung
R1-2111791 Intra-UE multiplexing and prioritization InterDigital, Inc.
R1-2111869 Intra-UE Multiplexing/Prioritization in Rel-17 Apple
R1-2111944 Intra-UE multiplexing enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2111990 Intra-UE Multiplexing/Prioritization ETRI
R1-2112014 Enhancements on intra-UE UCI multiplexing and channel collision resolution framework Sharp
R1-2112054 Discussion on Intra-UE multiplexing/prioritization LG Electronics
R1-2112083 Intra-UE multiplexing and prioritization TCL Communication Ltd.
R1-2112103 Discussion on intra-UE multiplexing/prioritization for Rel.17 URLLC NTT DOCOMO, INC.
R1-2112174 Discussion on intra-UE multiplexing ITRI
R1-2112211 Intra-UE multiplexing and prioritization for IOT and URLLC Qualcomm Incorporated
R1-2112287 Methods for intra-UE multiplexing and prioritization MediaTek Inc.
R1-2112387 Discussion on intra-UE multiplexing/prioritization for URLLC/IIoT WILUS Inc.
[107-e-NR-R17-IIoT-URLLC-03] – Yanping (CATT)
Email discussion on intra-UE multiplexing/prioritization
- Focus on simultaneous TX of PUCCH/PUSCH and multiplexing/overlapping resolution procedure for intra-UE multiplexing of UCI of different priorities on PUCCH and PUSCH
- 1st check point: November 15
- Final check point: November 19
R1-2112564 Summary #1 of email thread [107-e-NR-R17-IIoT-URLLC-03] Moderator (CATT)
From Nov 12th GTW session
Proposal:
Dynamic indication for enabling/disabling multiplexing of PUCCHs/PUSCHs with different priorities is supported in Rel-17 subject to UE capability.
· For an incapable UE, multiplexing of PUCCHs/PUSCHs with different priorities is enabled/disabled according to RRC configuration only.
· For a capable UE, it is up to gNB to configure whether the dynamic indication is enabled or not.
o dynamic indication can be enabled only if multiplexing of PUCCHs/PUSCHs with different priorities is enabled by RRC configuration.
o FFS: UE does not expect to receive contradicting indications in multiple DCIs associated with the overlapping channels
Rel-15
multiplexing timeline is applied required for all overlapping channels
(including dropped channels) involved in for multiplexing of PUCCHs/PUSCHs
with different priorities in Step 2.
· UE is not expected to receive a dynamic indication resulting demultiplexing of two previously multiplexed channels after the deadline to determine to multiplex PUCCHs/PUSCHs with different priorities according to Rel-15 multiplexing timeline
o Note: demultiplexing of two previously multiplexed channels means decoupling two channels already multiplexed, dropping one channel, and multiplexing the other channel with another channel(s).
· UE is not expected to be dynamically indicated to multiplex PUCCHs/PUSCHs with different priorities if the dynamic indication does not meet the Rel-15 multiplexing timeline.
Dropping/prioritization timeline in step 2 depends on UE capability
· Capability #1: Rel-15 multiplexing timeline is applied for dropping in step 2.
· Capability #2: Rel-16 cancellation timeline is applied for prioritization in step 2.
FFS whether multiplexing/cancellation timeline is required for a PUSCH supporting simultaneous transmission with PUCCH
Decision: As per email decision posted on Nov 13th,
Agreement:
For handling overlapping PUCCHs/PUSCHs with different priorities, Step 2 consists of the following sub-steps:
· Step 2.1: Resolve collision of LP PUCCHs and HP PUCCHs.
· Step 2.2: Resolve collision of PUCCHs and PUSCHs of different priorities.
Decision: As per email decision posted on Nov 16th,
Conclusion
Dynamic indication
for enabling/disabling multiplexing of PUCCHs/PUSCHs with different priorities
is NOT supported in Rel-17.
Note: Following the agreement made over email on Nov 20th (see below), the above conclusion does not applied anymore and is deleted.
Decision: As per email decision posted on Nov 18th,
Conclusion
There is no consensus in RAN1 to support simultaneous PUCCH/PUSCH transmission of same priority over different cells in Rel-17.
Conclusion
There is no consensus in RAN1 to support simultaneous PUCCH/PUSCH transmissions on different cells for intra-band CA in Rel-17.
R1-2112712 Summary #2 of email thread [107-e-NR-R17-IIoT-URLLC-03] Moderator (CATT)
From Nov 18th GTW session
Harmonized Proposal
If multiplexing of PUCCHs and/or PUSCHs with different priorities is enabled by RRC, support both of the following UE capabilities to resolve overlapping PUCCHs and/or PUSCHs with different priorities in step 2:
· Capability #1: It is not expected that Rel-15 multiplexing timeline is not met for all overlapping resultant channels after step 1. UE performs multiplexing or dropping of PUCCHs and/or PUSCHs with different priorities according to Rel-17 rules.
o Dynamic enabling/disabling is not supported for Capability #1
· Capability #3: Rel-17 multiplexing is dynamically enabled/disabled. The gNB is responsible to ensure that the UE meets the timeline.
Decision: As per email decision posted on Nov 20th,
Agreement
If multiplexing of PUCCHs and/or PUSCHs with different priorities is enabled by RRC, support both of the following UE capabilities to resolve collision of PUCCHs and/or PUSCHs with different priorities in step 2:
· The above behaviors of Capability#3 at least apply to resolving collision of two UL channels resulting from Step 1 with different priorities. FFS: more than two UL channels.
Note: “collision” refers to overlapping PUCCHs, overlapping PUCCH and PUSCH (excluding PUSCH supporting simultaneous transmission with PUCCH), overlapping PUSCHs on a same cell.
Note: “Rel-15 multiplexing timeline” means Rel15 timeline calculation in Rel-16 spec, including all the formula and all the values for the variables
Note: “Rel-16 prioritization timeline” means Rel-16 cancellation timeline calculation in Rel-16 spec, including all the formula and all the values for the variables
[107-e-NR-R17-IIoT-URLLC-04] – Jia (OPPO)
Email discussion on intra-UE multiplexing/prioritization
- Focus on PHY prioritization of overlapping DG-PUSCH/CG-PUSCH and remaining details on intra-UE multiplexing of UCI of different priorities on PUCCH and PUSCH (except multiplexing/overlapping resolution procedure)
- 1st check point: November 15
- Final check point: November 19
R1-2112604 Summary#1 of email thread [107-e-NR-R17-IIoT-URLLC-04] Moderator (OPPO)
Decision: As per email decision posted on Nov 16th,
Agreement
For collision of LP DG-PUSCH and HP
CG-PUSCH of different priorities, the cancellation is applied per actual
repetition, if LP DG-PUSCH and/or HP CG-PUSCH is repeated.
R1-2112667 Summary#2 of email thread [107-e-NR-R17-IIoT-URLLC-04] Moderator (OPPO)
From Nov 18th GTW session
Agreement
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a PUSCH in R17, if HP HARQ-ACK, LP HARQ-ACK, and LP CSI consisting of two parts would be transmitted on LP PUSCH conveying UL-SCH,
· The CSI part 2 is dropped.
· Reuse R15 HARQ-ACK rate matching/puncturing and RE mapping for HP HARQ-ACK in principle. FFS details.
· Reuse R15 CSI part 1 rate matching and RE mapping for LP HARQ-ACK.
· Reuse R15 CSI part 2 rate matching and RE mapping for LP CSI part 1.
· FFS for LP CSI consisting of single part.
Note: Apple raised concern on CSI being dropped unnecessarily which could cause performance and degrade usefulness of URLLC enhancement.
Agreement
For the overlapping between LP CG and HP DG, if MAC delivers two MAC PDUs to PHY, PHY layer can make the prioritization so that the UE is expected to cancel the overlapping low priority CG PUSCH by the first overlapping symbol at the latest.
· On top of Rel-16 cancellation time (N2+d1) for PUCCH/PUCCH or PUCCH/PUSCH collision, additional time d3 is needed (which results N2+d1+d3 in total cancellation time) for LP CG-PUSCH and HP DG-PUSCH collision resolution.
o
(Working assumption) d3 = {0, 
}symbol(s) upon UE capability report, where 
for SCS=15/30/60/120kHz, respectively.
Agreement
For determining the PUCCH resource to carry
the multiplexed high-priority and low-priority HARQ-ACKs, if 
·
The number of RBs is 
. Then follow Rel-15 procedure, i.e., LP
HARQ-ACK is mapped to the rest REs after HP HARQ-ACK.
Decision: As per email decision posted on Nov 19th,
Agreement
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a PUCCH in R17,
· At least for PUCCH format 3/4, use the HP UCI bit number and HP RE number for ∆TF,b,f,c(i) formula selection and calculation
· For PUCCH format 1, use the total UCI bit number for ∆TF,b,f,c(i) calculation.
· FFS for PUCCH format 2.
Agreement
For collision of HP DG-PUSCH and LP CG-PUSCH, the cancellation is applied per actual repetition, if HP DG-PUSCH and/or LP CG-PUSCH is repeated.
Final summary in
R1-2112785 Summary#3 of email thread [107-e-NR-R17-IIoT-URLLC-04] Moderator (OPPO)
Including any RAN1 involvement in propagation delay compensation enhancements (including mobility issues, if any) and CSI feedback enhancements.
R1-2110917 Discussion on propagation delay compensation enhancements ZTE
R1-2111008 Remaining issues on propagation delay compensation enhancements vivo
R1-2111141 Discussion on enhancements for PDC and CSI Nokia, Nokia Shanghai Bell
R1-2111191 Propagation Delay Compensation Enhancements for Time Synchronization Ericsson
R1-2111251 Discussion on propagation delay compensation enhancements CATT
R1-2111344 Enhancement for support of time synchronization OPPO
R1-2111492 Remaining open issues for propagation delay compensation Intel Corporation
R1-2111733 Discussion for propagation delay compensation enhancements Samsung
R1-2111926 Enhancements for support of time synchronization Huawei, HiSilicon
R1-2112055 Discussion on propagation delay compensation enhancements LG Electronics
R1-2112212 Enhancements for support of time synchronization for enhanced IIoT and URLLC Qualcomm Incorporated
[107-e-NR-R17-IIoT-URLLC-05] – Chengyan (Huawei)
Email discussion on propagation delay compensation enhancements
- 1st check point: November 15
- Final check point: November 19
Decision: As per email decision posted on Nov 15th,
Agreement
If RTT-based PDC is supported, a single granularity 32Tc (i.e. k=5) is supported for Rx-Tx measurement report.
R1-2112476 Feature lead summary#1 on propagation delay compensation enhancements Moderator (Huawei)
From Nov 16th GTW session
Working Assumption
For Rel-17
· Support RTT-based PDC method
· Support PDC method based on legacy TA-based mechanism
o No RAN1/RAN4 specification impact expected
R1-2112477 Feature lead summary#2 on propagation delay compensation enhancements Moderator (Huawei)
R1-2112728 Feature lead summary#3 on propagation delay compensation enhancements Moderator (Huawei)
From Nov 19th GTW session
Above Working Assumption is converted to:
Agreement
For Rel-17
· Support RTT-based PDC method
· Support PDC method based on legacy TA-based mechanism
o No RAN1/RAN4 specification impact expected
Agreement
For RTT-based PDC, existing definitions of UE Rx – Tx time difference (i.e. section 5.1.30 in TS 38.215) and gNB Rx – Tx time difference (i.e. section 5.2.3 in TS 38.215) are reused, with updates at least to reflect the single pair of TRS/PRS and SRS configured for RTT-based PDC.
Agreement
Send an LS to RAN2 and RAN4 with the content including:
· The agreements made in RAN1#107-e for propagation delay compensation.
· Ask RAN4 to define the following for RTT-based propagation delay compensation:
o UE Rx-Tx time difference measurement accuracy based on CSI-RS for tracking
o UE Rx-Tx time difference measurement accuracy based on PRS (including reuse existing spec if appropriate)
o gNB Rx-Tx time difference absolute accuracy based on SRS (including reuse existing spec if appropriate)
· Inform RAN4 that enhanced TA-based PDC with reduced Te and enhanced TA command granularity is precluded in RAN1.
Conclusion
For RTT-based PDC, it is assumed that the transmission of DL TRS/PRS, UL SRS and reference time information are associated with a same TRP.
Note: No RAN1 specification impact is expected for this conclusion
Agreement
For RTT-based propagation delay compensation, the Rx-Tx time difference is reported via RRC signalling.
Conclusion
The reporting range of Rx-Tx time difference measurement for RTT-based PDC is up to RAN4.
R1-2112729 Draft LS on propagation delay compensation Huawei
Decision: As per email decision posted on Nov 20th, the draft LS is endorsed. Final LS to RAN2/RAN4 is approved in R1-2112834.
Final summary in R1-2112835.
[107-e-NR-R17-IIoT-URLLC-06] – Paul (InterDigital)
Email discussion on remaining issues on CSI feedback enhancement
- 1st check point: November 15
- Final check point: November 19
R1-2112694 Summary #1 of [107-e-NR-R17-IIoT-URLLC-06] on remaining issues on CSI feedback enhancement Moderator (InterDigital, Inc.)
Please refer to RP-210854 for detailed scope of the WI. Please also refer to slide 4 of R1-2200001 for additional guidance for this e-meeting. Relevant incoming LSs in R1-2200011.
[107bis-e-R17-RRC-IIoT-URLLC] – Klaus (Nokia)
Email discussion on Rel-17 RRC parameters for IIoT and URLLC
- Email discussion to start on January 20 and end by January 25
R1-2200777 Summary of [107bis-e-R17-RRC-IIoT-URLLC] Email discussion on Rel-17 RRC parameters for IIoT and URLLC Moderator (Nokia)
Document is noted. For consolidation under 8 in [107bis-e-R17-RRC].
R1-2200778 List of agreements of Rel-17 URLLC/IIoT WI (post RAN1#107bis-e) WI rapporteur (Nokia)
R1-2200017 HARQ-ACK Feedback Enhancements for URLLC/IIoT Nokia, Nokia Shanghai Bell
R1-2200037 UE feedback enhancements for HARQ-ACK Huawei, HiSilicon
R1-2200080 Remaining issues on HARQ-ACK enhancements for Rel-17 URLLC vivo
R1-2200107 Discussion on HARQ-ACK enhancements for eURLLC ZTE
R1-2200147 Remaining issues on HARQ-ACK feedback enhancements CATT
R1-2200178 Remaining issues in HARQ-ACK enhancements for URLLC Sony
R1-2200198 Remaining issues for HARQ-ACK feedback enhancements Samsung
R1-2200232 Discussion on HARQ-ACK feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
R1-2200269 UE feedback enhancements for HARQ-ACK CAICT
R1-2200274 Discussion on HARQ-ACK feedback enhancements for Rel-17 URLLC Spreadtrum Communications
R1-2200294 HARQ-ACK enhancement for IOT and URLLC Qualcomm Incorporated
R1-2200319 Discussion on one-shot triggering of HARQ retransmission Panasonic Corporation
R1-2200343 HARQ-ACK enhancements for Rel-17 URLLC/IIoT OPPO
R1-2200356 UE feedback enhancements for HARQ-ACK ETRI
R1-2200372 Remaining issues on UE HARQ feedback enhancements Intel Corporation
R1-2200395 Remaining issues on HARQ enhancements for URLLC InterDigital, Inc.
R1-2200414 Rel-17 UE feedback enhancements for HARQ-ACK Apple
R1-2200440 HARQ-ACK Enhancements for IIoT/URLLC Ericsson (Late submission)
R1-2200484 Discussion on some remaining issues for UE HARQ-ACK feedback enhancements China Telecom
R1-2200516 UE feedback enhancements for HARQ-ACK NEC
R1-2200530 HARQ-ACK feedback enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2200556 On UE feedback enhancements for HARQ-ACK MediaTek Inc.
R1-2200571 Discussion on UE feedback enhancement for HARQ-ACK LG Electronics
[107bis-e-R17-IIoT-URLLC-01] – Klaus (Nokia)
Email discussion on UE feedback enhancements for HARQ-ACK
- 1st check point: January 20
- Final check point: January 25
R1-2200020 Moderator summary #1 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
From Jan 17th GTW session
Proposal 1: SPS HARQ-ACK deferral is supported also for half-duplex CA UEs.
· FFS details
Continue email discussions and to conclude on the next GTW session for HARQ.
Conclusion
There is no consensus for introducing further specification support for the following:
· PUCCH cell switching between cells with shared spectrum channel access (in any mode)
· PUCCH cell switching between a cell with licensed spectrum and a cell with shared spectrum channel access (in any mode)
Proposal 5:
For dynamic PUCCH cell switching, the HARQ-ACK of SPS PDSCH without associated DCI except the first SPS PDSCH activated by the activation DCI is to be transmitted on PCell / PSCell / PUCCH-SCell independently of the dynamically indicated PUCCH cell in the SPS activation DCI.
Decision: As per email decision posted on Jan 19th,
Agreement:
For one-shot HARQ-ACK re-transmission, the value range for HARQ re-tx offset is given by [min_HARQ_retx_offset_value, max_HARQ_retx_offset_value] with an indication of 1 slot / sub-slot within that range.
· FFS the fixed value of min_HARQ_retx_offset_value
· FFS the fixed value of max_HARQ_retx_offset_value
Conclusion
For one-shot HARQ re-transmission on PUCCH, the UE determines no PDSCH is scheduled when the triggering bit is set to ‘1’ (i.e. the UE does not need to in addition check any specific resource allocation setting).
Agreement:
For PUCCH cell switching based on semi-static time domain pattern, the Type 1 HARQ-ACK codebook construction is based on the k1 set(s) of the PCell / SPCell / PUCCH SCell.
Agreement:
Re-add the RRC parameter for the DCI field configuration in row 17 of the Enh. Type-3 HARQ-ACK codebook for the primary PUCCH cell group (that was lost when moving from v006 to v007 in the final RRC parameter discussions in RAN1#107-e, currently we only have the configuration for the secondary PUCCH cell group)? i.e.,
|
pdsch-HARQ-ACK-enhType3DCIfield |
Enables the enhanced Type 3 CB through a new DCI field to indicate the enhanced Type 3 HARQ-ACK codebook in the primary cell group if the more than one enhanced Type 3 HARQ-ACK codebook is configured for the primary PUCCH cell group. |
Enabled |
Agreement:
Support separate configuration of the DCI field presence for enh. Type 3 HARQ-ACK CB for DCI format 1_2 (i.e. pdsch-HARQ-ACK-enhType3DCIfieldDCI-1-2 as discussed in RAN1#107-e already)
R1-2200729 Moderator summary #2 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
From Jan 19th GTW session
Conclusion: (regarding proposal 1 discussed in Jan 17th GTW)
There is no consensus to support SPS HARQ-ACK deferral for half-duplex CA UEs in Rel-17.
Agreement
RAN1 confirms the following RAN1#107-e working assumption:
|
Working Assumption For one-shot triggering of HARQ re-transmission, in addition to one-shot triggering of HARQ re-transmission after the initial PUCCH transmission slot, the triggering is supported before the initial PUCCH transmission slot · Re-transmission triggering does not change processing for the initial PUCCH transmission (i.e., HARQ multiplexing / dropping / transmission) · The UE expects the PUCCH carrying the HARQ-ACK re-transmission to be scheduled in a slot/sub-slot after the initial PUCCH transmission slot/sub-slot. · The support for the triggering before the initial PUCCH transmission slot is subject to separate UE capability indication |
Conclusion
There is no consensus to support MAC CE activation indicating a set of values of pucch-SpatialRelationInfoId applicable to the alternative PUCCH sSCell for PUCCH cell switching in Rel-17.
Conclusion
There is no consensus to support joint operation of SPS HARQ-ACK deferral and PUCCH repetition in Rel-17.
Decision: As per email decision posted on Jan 21st,
Conclusion
The operation of simultaneous configuration of Rel-16 Type 3 HARQ-ACK codebook or enhanced Type 3 HARQ-ACK codebook triggering and SPS HARQ-ACK deferral is further clarified as:
· If the UE detects a DCI format in a PDCCH reception that triggers a PUCCH transmission with a Type-3 or enhanced Type-3 HARQ-ACK codebook in a slot, the UE stops the procedure to determine the earliest second slot in that slot.
· The pending SPS HARQ information for deferral is not appended to the Type-3 or enhanced Type 3 CB in that slot.
R1-2200730 Moderator summary #3 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
From Jan 21st GTW session
Conclusion
There is no consensus to support joint configuration of PUCCH cell switching based on dynamic indication and SPS HARQ-ACK deferral in Rel-17.
Agreement
For dynamic PUCCH cell switching, the Type 1 HARQ-ACK codebook construction is based on the k1 set(s) of the dynamically indicated PUCCH cell.
Decision: As per email decision posted on Jan 22nd,
Agreement
The following TP to 38.213 is endorsed for the editor’s CR.
|
9.2.5.4 UE procedure for deferring HARQ-ACK for SPS PDSCH
If a UE is provided spsHARQdeferral and, after performing the procedures in clauses 9 and 9.2.5 to resolve overlapping among PUCCHs and PUSCHs in a first slot, the UE determines a PUCCH resource for a PUCCH transmission with first HARQ-ACK information bits for SPS PDSCH receptions that the UE would report for a first time, and the PUCCH resource - is provided by SPS-PUCCH-AN-List as described in clause 9.2.1, or by n1PUCCH-AN if SPS-PUCCH-AN-List is not provided - overlaps with a symbol indicated as downlink by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigDedicated, or indicated for a SS/PBCH block by ssb-PositionsInBurst, or belonging to a CORESET associated with a Type0-PDCCH CSS set the UE - determines an earliest second slot and, after performing the procedures in clauses 9 and 9.2.5 to resolve overlapping among PUCCHs and PUSCHs, a PUSCH or a PUCCH in the earliest second slot to multiplex HARQ-ACK information bits that include second HARQ-ACK information bits from the first HARQ-ACK information bits - if the UE detects a DCI format in a PDCCH reception that triggers a PUCCH transmission with a Type-3 HARQ-ACK codebook in a slot as described in clause 9.1.4, the UE stops the procedure to determine the earliest second slot in the slot - if the UE is provided a periodic cell switching pattern for PUCCH transmissions by pucch-sSCellPattern, the UE determines the earliest second slot and a corresponding cell based on the periodic cell switching pattern as described in clause 9.A |
Agreement
For one-shot HARQ-ACK re-transmission,
· the minimum value for the HARQ re-tx offset min_HARQ_retx_offset_value is -7.
· the maximum value for the HARQ re-tx offset max_HARQ_retx_offset_value is 24.
·
Note: UE capability
reporting on the UE supported value of the minimum value and maximum
value range for HARQ_retx_offset in the scope of [min_HARQ_retx_offset_value, max_HARQ_retx_offset_value ] that can be indicated by the gNB for the UE can be further discussed
in UE capabilities
Agreement
For one-shot triggering of HARQ-ACK re-transmission, the HARQ_retx_offset is indicated by the bits of the MCS field for transport block 1.
R1-2200775 Moderator summary #4 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
From Jan 25th GTW session
Agreement
Support the simultaneous configuration of one-shot triggering of HARQ re-transmission and SPS deferral
· One-shot HARQ-ACK re-transmission can trigger re-transmission SPS HARQ-ACK enabled with deferring from the initial SPS HARQ deferral slot.
· If the PUCCH slot indicated by the HARQ_retx_offset is the ‘target’ or earliest ‘second’ slot for SPS HARQ-ACK deferral, the HARQ-ACK CB including the deferred SPS HARQ-ACK bits will be retransmitted in the new retransmission PUCCH triggered by one-shot triggering DCI.
· For the SPS HARQ-ACK deferral procedure, the PUCCH slot with a one-shot triggered HARQ-ACK CB is regarded as a valid potential target PUCCH slot for SPS HARQ-ACK deferral with same PHY priority (at least for operation with Rel-16 PHY prioritization) as the PHY priority of the triggered one-shot HARQ-ACK re-transmission.
o If the PUCCH slot with a one-shot triggered HARQ-ACK CB is determined by the UE as target or earliest second PUCCH slot for SPS HARQ-ACK deferral, the deferred SPS HARQ-ACK in a target slot is appended to the re-transmitted HARQ-ACK CB and initial, new HARQ-ACK (if any) following the operation of SPS HARQ-ACK deferral procedure.
Conclusion
There is no consensus on the support of HARQ-ACK CB size indication in the triggering DCI for HARQ-ACK re-transmission.
Conclusion
There is no consensus to support the following in Rel-17:
· For one-shot HARQ re-transmission on PUCCH, if certain HARQ process IDs of the requested HARQ CB to be retransmitted is replaced by new HARQ bits, the UE transmits the new content of HARQ process(es) being updated.
Decision: As per email decision posted on Jan 26th,
Agreement
For PUCCH repetition and one-shot HARQ-ACK re-transmission, if the gNB triggers the HARQ-ACK CB re-transmission from a PUCCH slot indicated by HARQ_retx_offset where a HARQ-ACK in a first PUCCH is dropped due to overlapping with another, second PUCCH, where the first PUCCH and second PUCCH have the same L1 priority, and at least one of the first PUCCH and the second PUCCH is subject to a repetition, the UE re-transmits the HARQ-ACK CB of the second PUCCH from the slot.
Final summary in R1-2200776.
R1-2200038 Uplink enhancements for URLLC in unlicensed controlled environments Huawei, HiSilicon
R1-2200081 Remaining issues on enhancements for unlicensed band URLLC/IIoT vivo
R1-2200108 Discussion on unlicensed band URLLC/IIoT ZTE
R1-2200166 Enhancements for unlicensed band URLLC/IIoT NEC
R1-2200179 Remaining issues in unlicensed URLLC Sony
R1-2200295 Uplink enhancements for URLLC in unlicensed controlled environments Qualcomm Incorporated
R1-2200357 Remaining issues on unlicensed band URLLC/IIoT ETRI
R1-2200373 Remaining Clarifications for Enabling URLLC/IIoT in Unlicensed Band Intel Corporation
R1-2200396 Enhancements for unlicensed band URLLC/IIoT InterDigital, Inc.
R1-2200415 Remaining issues on URLLC uplink enhancements for unlicensed spectrum Apple
R1-2200441 Enhancements for IIoT/URLLC on Unlicensed Band Ericsson (Late submission)
R1-2200496 Enhancements for unlicensed band URLLC/IIoT Sharp
R1-2200572 Discussion on unlicensed band URLLC/IIOT LG Electronics
R1-2200634 Remaining issues on enhancement for unlicensed URLLC/IIoT WILUS Inc.
[107bis-e-R17-IIoT-URLLC-02] – Sorour (Ericsson)
Email discussion on unlicensed band URLLC/IIoT
- 1st check point: January 20
- Final check point: January 25
R1-2200691 Summary#1 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
R1-2200692 Summary#2 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
Decision: As per email decision posted on Jan 21st,
Agreement
In semi-static channel occupancy, the procedures for intra-period scheduled UL applies to cross-carrier scheduling case if the timing of the scheduled UL transmission and the corresponding scheduling DCI are confined within the same gNB period on the carrier on which the UL transmission is scheduled. Otherwise, the procedures for cross-period scheduled UL transmissions should apply for the cross-carrier scheduled UL transmission.
Agreement
Text proposal 2-2 in section 1.1.1 of R1-2200692 for Clause 4.3.1.2.4.1 and Clause 4.3.1.2.4.2 of TS 37.213 is endorsed for the editor’s CR.
· Including editorial updates to change “carrier(s)” to “carrier” in several places that was missed. Potential remaining cases can be handled during implementation of editor’s CR.
Agreement
Text proposal 3-1 in section 1.1.1 of R1-2200692 for Clauses 4.3.1.2.1, 4.3.1.2.2, 4.3.1.2.4.1 and 4.3.1.2.4.2 of TS 37.213 is endorsed for the editor’s CR.
Agreement
Text proposal 3-2 in section 1.1.1 of R1-2200692 for Clauses 7.3.1.1 of TS 38.212 is endorsed for the editor’s CR.
Agreement
Text proposal 4-1 in section 1.1.1 of R1-2200692 for Clause 4.3.1.2.1 and Clause 4.3.1.2.2 of TS 37.213 is endorsed for the editor’s CR.
Decision: As per email decision posted on Jan 22nd,
Conclusion
· If UE-initiated COT in semi-static channel access mode is enabled for a UE, when operating on multiple LBT BWs on a carrier, the assumptions regarding the COT initiator for a configured UL transmission may not be aligned across all LBT BWs for the configured UL transmission
Agreement
The following TPs for TS37.213 is endorsed for the editor’s CR
< Start of text proposal to TS 37.213 Clause 4.3.1.2.1>
4.3.1.2.1 Channel occupancy initiated by gNB and sensing procedures
*** Unchanged text is omitted ***
·
If the gap between the UL transmission burst(s)
and any previous DL transmission burst in that period is more than 
, the UL
transmission burst(s) may be transmitted if the channel is sensed to be idle
for at least a sensing slot duration 
within a 
interval ending
immediately before the UL transmission burst(s).
*** Unchanged text is omitted ***
4.3.1.2.2 Channel occupancy initiated by UE and sensing procedures
*** Unchanged text is omitted ***
·
If the gap between the DL transmission burst(s)
and any previous UL transmission burst in that period is more than , the DL
transmission burst(s) may be transmitted if the channel is sensed to be idle
for at least a sensing slot duration within a interval ending
immediately before the DL transmission burst(s).
*** Unchanged text is omitted ***
< End of text proposal>
R1-2200693 Summary#3 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
Decision: As per email decision posted on Jan 24th,
Agreement
· Proposal 6-4 (updated) as in section 1.1.3 of R1-2200693 (updated TP to TS 37.213 clause 4.3.1.2.3 and clause 4.3.2) is endorsed for inclusion in the editor’s CR.
Agreement
For semi-static channel access mode when a UE is enabled to initiate a COT, for a nominal repetition of a PUSCH transmission Type B across multiple LBT BWs, if the COT initiator assumption is not aligned among the LBT BWs, the nominal repetition is dropped if there are invalid symbols due to overlapping of the nominal repetition with an idle duration of either gNB’s FFP or UE’s FFP.
Conclusion
For semi-static channel access mode when a UE is enabled to initiate a COT,
· For a scheduled UL transmission across multiple LBT BWs, the same COT initiator assumption is made across all of the LBT BWs.
· For a UL transmission other than a nominal repetition of a PUSCH transmission Type B that is configured across multiple LBT BWs, if in an LBT BW of the UL transmission overlaps with an idle duration corresponding to a period that its corresponding COT is associated with, the UL transmission is dropped.
Conclusion
· In semi-static channel access mode, when UE is enabled to initiate COT, UL transmission based on UE-initiated COT for random access procedures in RRC-connected mode is supported where the procedures for configured and scheduled UL transmissions are applicable.
Agreement
In semi-static channel access mode, when UE is enabled to initiate COT,
· UL transmission based on UE-initiated COT for contention-free random access procedure in RRC-connected mode is allowed for PRACH and corresponding PUSCH transmissions.
· RAR grant corresponding to the PRACH transmission for the contention-free random access procedure indicates the COT initiator associated with the PUSCH transmission scheduled by the RAR grant based on Table 7.3.1.1.1-4A of TS 38.212.
· UL transmission based on UE-initiated COT for contention-based random access procedure in RRC-conneted mode is not allowed.
Agreement
· Proposal 8-2 (updated 2) as in section 1.1.3 of R1-2200693 (updated TP to TS 37.213 clause 4.3.1.2.1) is endorsed for inclusion in the editor’s CR
Decision: As per email decision posted on Jan 26th,
Agreement
The text proposals captured as in section 1.1.3 of R1-2200693 (TP 1-1 for Clause 4.3.1.2.3 of TS 37.213, TP 1-2 for Clause 4.3.1.2.1 and Clause 4.3.1.2.2 of TS 37.213) are endorsed for the editor’s CR for TS37.213.
Agreement
For semi-static channel access mode when a UE is enabled to initiate a COT, if a nominal repetition of a configured PUSCH transmission repetition Type B shares a gNB-initiated COT and overlaps with an idle duration of the corresponding gNB’s FFP as well as an idle duration of a UE’s FFP where the UE has initiated the corresponding COT, the configured UL transmission is dropped.
Final summary in R1-2200694.
R1-2200012 Intra-UE multiplexing and prioritization New H3C Technologies Co., Ltd.
R1-2200018 On UL intra-UE prioritization and multiplexing enhancements Nokia, Nokia Shanghai Bell
R1-2200039 Intra-UE multiplexing enhancements Huawei, HiSilicon
R1-2200082 Remaining issues on intra-UE Multiplexing/Prioritization for Rel-17 URLLC vivo
R1-2200109 Discussion on enhanced intra-UE multiplexing ZTE
R1-2200148 Remaining issues on intra-UE multiplexing and prioritization CATT
R1-2200180 Remaining issues in intra-UE multiplexing & prioritisation Sony
R1-2200199 Remaining issues for Intra-UE Multiplexing/Prioritization Samsung
R1-2200233 Discussion on intra-UE multiplexing/prioritization for Rel.17 URLLC NTT DOCOMO, INC.
R1-2200275 Discussion on intra-UE multiplexing/prioritization Spreadtrum Communications
R1-2200296 Intra-UE multiplexing and prioritization for IOT and URLLC Qualcomm Incorporated
R1-2200320 Discussion on intra-UE multiplexing with different priorities Panasonic Corporation
R1-2200344 Enhancements on intra-UE multiplexing/prioritization OPPO
R1-2200358 Intra-UE Multiplexing/Prioritization ETRI
R1-2200365 Intra-UE multiplexing and prioritization InterDigital, Inc.
R1-2200374 Remaining Open Details of Intra-UE Uplink Channel Multiplexing and Prioritization Intel Corporation
R1-2200770 Rel-17 intra-UE Multiplexing/Prioritization Apple (rev of R1-2200416)
R1-2200442 Intra-UE Multiplexing/Prioritization Enhancements for IIoT/URLLC Ericsson (Late submission)
R1-2200485 Discussion on some remaining issues for intra-UE multiplexing and prioritization China Telecom
R1-2200492 Remaining Issues on Intra-UE Multiplexing/Prioritization Quectel, Langbo
R1-2200497 Intra-UE UCI multiplexing and channel collision resolution with different priorities Sharp
R1-2200517 Discussion on Intra-UE prioritization and multiplexing NEC
R1-2200531 Intra-UE multiplexing enhancement for IIoT/URLLC Lenovo, Motorola Mobility
R1-2200562 Discussion on intra-UE multiplexing and prioritization ITRI
R1-2200573 Discussion on Intra-UE multiplexing/prioritization LG Electronics
R1-2200635 Remainng issues on intra-UE multiplexing/prioritization for URLLC/IIoT WILUS Inc.
[107bis-e-R17-IIoT-URLLC-03] – Yanping (CATT)
Email discussion on intra-UE multiplexing/prioritization
- Focus on simultaneous TX of PUCCH/PUSCH and multiplexing/overlapping resolution procedure for intra-UE multiplexing of UCI of different priorities on PUCCH and PUSCH (Capability 1 only)
- 1st check point: January 20
- Final check point: January 25
R1-2200704 Summary #1 of email thread [107bis-e-R17-IIoT-URLLC-03] Moderator (CATT)
From Jan 17th GTW session
R1-2200725 Summary #2 of email thread [107bis-e-R17-IIoT-URLLC-03] Moderator (CATT)
From Jan 18th GTW session
Conclusion
For resolving collision of PUCCHs and/or PUSCHs with different priorities in step 2, a resultant PUCCH with HP and LP UCI is not expected to be overlapped with a HP PUCCH.
· FFS whether a resultant PUCCH with HP and LP UCI can be overlapped with a HP PUSCH.
Agreement
For resolving collision of LP PUCCHs and HP PUCCHs in step 2.1, a HP PUCCH with HARQ-ACK is not expected to be overlapped with multiple LP PUCCHs with HARQ-ACK.
· It’s up to the editor whether/how to capture this.
Agreement
For resolving collision of PUCCHs and PUSCHs of different priorities in step 2.2, LP PUSCH(s) overlapping with HP PUCCH including positive SR are dropped.
Agreement
simultaneousPUCCH-PUSCH-secondaryPUCCHgroup is supported to enable simultaneous PUCCH and PUSCH transmissions with different priorities within the secondary PUCCH cell group separately from primary PUCCH cell group.
R1-2200737 Summary #3 of email thread [107bis-e-R17-IIoT-URLLC-03] Moderator (CATT)
From Jan 19th GTW session
R1-2200738 Summary #4 of email thread [107bis-e-R17-IIoT-URLLC-03] Moderator (CATT)
From Jan 20th GTW session
Working Assumption
For resolving collision of PUCCHs and PUSCHs of different priorities in step 2.2, LP PUSCH(s) overlapping with HP PUCCH which carries positive SR are dropped before UCI multiplexing.
· Step 1.2 behavior is not affected by the above
Agreement
· The above is considered an error case
R1-2200739 Summary #5 of email thread [107bis-e-R17-IIoT-URLLC-03] Moderator (CATT)
From Jan 21st GTW session
Agreement
If the simultaneous PUCCH/PUSCH transmission is enabled, a PUSCH that can be simultaneously transmitted with a PUCCH is excluded from overlapping channels for multiplexing the UCI of the PUCCH and for intra-UE prioritization with the PUCCH.
· Note: For intra-UE multiplexing, above is for step 2-2. For intra-UE prioritization, above is applied after step 1.
· FFS: How to capture this in the specifications
Conclusion
If the simultaneous PUCCH/PUSCH transmission is enabled, the timeline conditions of intra-UE multiplexing/prioritization of PUCCHs and PUSCHs with different priorities is not applicable to a PUSCH that can be simultaneously transmitted with a PUCCH.
R1-2200771 Summary #6 of email thread [107bis-e-R17-IIoT-URLLC-03] Moderator (CATT)
From Jan 24st GTW session
Agreement
For resolving collision of PUCCHs with different priorities in step 2.1, if resultant PUCCH with HP and LP UCI collides with LP PUCCH without HARQ ACK, the LP PUCCH is dropped.
· A resultant PUCCH with HP and LP UCI is not expected to be overlapped with a LP PUCCH with HARQ-ACK.
Agreement
For resolving collision of PUCCHs of different priorities without repetitions within a time unit, Step 2.1 consists of the following sub-steps:
· Step 2.1-1: Determine a reference PUCCH resource
· Step 2.1-2: Select O PUCCH resource(s) overlapping with the reference PUCCH resource.
· Step 2.1-3: Apply Rel-17 intra-UE multiplexing/dropping rules to resolve overlapping among the reference PUCCH resource and O PUCCH resource(s).
· Step 2.1-4: Loop Step 2.1-1) ~ Step 2.1-3) until there are no overlapping PUCCHs in the time unit.
· FFS details
Agreement
For resolving collision of PUCCHs of different priorities without repetition within a time unit, down-select from the following options:
· Option 1:
o The reference PUCCH resource is determined as in Rel-15, i.e. based on the starting symbol and duration
o In step 2.1-2, select up to one PUCCH resource overlapping with the reference PUCCH resource according to Rel-15 pseudo code
· Option 2:
o The reference PUCCH resource is determined as in Rel-15, i.e. based on the starting symbol and duration
o In step 2.1-2, select all the PUCCH resources overlapping with the reference PUCCH resource according to Rel-15 pseudo code
· Option 3:
o The reference PUCCH resource is determined by prioritizing HP PUCCH over LP PUCCH on top of Rel-15 rules
o In step 2.1-2, select all the PUCCH resources overlapping with the reference PUCCH resource according to Rel-15 pseudo code
· Option 4:
o The reference PUCCH resource is determined by prioritizing LP PUCCH carrying HARQ-ACK on top of Rel-15 rules
o In step 2.1-2, If a LP PUCCH carrying HARQ-ACK overlaps with multiple HP PUCCHs and one of the HP PUCCH includes HARQ-ACK, only select the HP PUCCH including HARQ-ACK in step 2.1-2; otherwise, select all the PUCCH resources overlapping with the reference PUCCH resource according to Rel-15 pseudo code
FFS: Details on time units for all options
Working Assumption
For resolving collision of PUCCHs of different priorities without repetition within a time unit, the time unit of HP HARQ-ACK is used. For a LP PUCCH overlapping with multiple time units, down-select from:
· Alt. 1: the LP PUCCH is associated with the first time unit with overlapping HP PUCCH(s)
· Alt. 2: the LP PUCCH is associated with the first time unit with overlapping HP PUCCH with HARQ-ACK if any. Otherwise, the LP PUCCH is associated with the first time unit with overlapping HP PUCCH(s).
· Alt. 3: the LP PUCCH is associated with the last time unit with overlapping HP PUCCH(s)
Agreement
To apply Rel-17 intra-UE multiplexing/dropping rules to resolve overlapping among the reference PUCCH resource and O PUCCH resource(s) in step 2.1-3, LP PUCCH(s) without HARQ ACK are dropped before multiplexing if multiplexing is to be performed.
R1-2200772 Summary #7 of email thread [107bis-e-R17-IIoT-URLLC-03] Moderator (CATT)
From Jan 25th Jan GTW session
Conclusion
A resultant PUCCH with HP and LP UCI overlapping with a HP PUSCH is considered an error case.
Agreement
For resolving collision of PUCCHs and PUSCHs of different priorities in step 2.2, Rel-15/16 rule is reused for PUSCH selection for HARQ ACK multiplexing
· FFS whether/how dropping is performed before UCI multiplexing
· Note: The priorities of PUCCH and PUSCH candidates for multiplexing in step 2.2 are different
Decision: As per email decision posted on Jan 26th,
Conclusion
A UE is not expected to be enabled with prioritizationBetweenLP-DG-PUSCHandHP-CG-PUSCH or prioritizationBetweenHP-DG-PUSCHandLP-CG-PUSCH for a cell group if UCI-MuxWithDifferentPriority or UCI-MuxWithDifferentPriority-secondaryPUCCHgroup is enabled for the same cell group.
[107bis-e-R17-IIoT-URLLC-04] – Jia (OPPO)
Email discussion on intra-UE multiplexing/prioritization
- Focus on PHY prioritization of overlapping DG-PUSCH/CG-PUSCH and remaining details on intra-UE multiplexing of UCI of different priorities on PUCCH and PUSCH (except multiplexing/overlapping resolution procedure)
- 1st check point: January 20
- Final check point: January 25
R1-2200715 Summary#1 of email thread [107bis-e-R17-IIoT-URLLC-04] Moderator (OPPO)
From Jan 18th GTW session
Agreement
When a PUCCH carrying HP SR with PF0/1 overlaps with a PUCCH carrying LP HARQ-ACK with PF2/3/4:
· For positive SR, transmit SR on the SR PUCCH resource and drop HARQ-ACK.
· For negative SR, transmit HARQ-ACK only on the HARQ-ACK PUCCH resource.
Note: It was agreed to support multiplexing a LP HARQ-ACK and a HP SR into a PUCCH for some HARQ-ACK/SR PF combinations in Rel-17.
Agreement
·
For
multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK
into a low-priority (LP) PUSCH in R17, if HP HARQ-ACK, LP
HARQ-ACK, and HP/LP CSI consisting of two
parts would be transmitted on HP/LP PUSCH
not conveying UL-SCH, UE follows the same behaviour as that in case of PUSCH
conveying UL-SCH.
·
For
multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK
into a high-priority (HP) PUSCH in R17, if HP HARQ-ACK, LP
HARQ-ACK, and HP/LP CSI consisting of two
parts would be transmitted on HP/LP PUSCH
not conveying UL-SCH, UE follows the same behaviour as that in case of PUSCH
conveying UL-SCH.
Decision: As per email decision posted on Jan 20th,
Agreement
The following working assumption is confirmed
For the overlapping between LP CG and HP DG, if MAC delivers two MAC PDUs to PHY, PHY layer can make the prioritization so that the UE is expected to cancel the overlapping low priority CG PUSCH by the first overlapping symbol at the latest.
· On top of Rel-16 cancellation time (N2+d1) for PUCCH/PUCCH or PUCCH/PUSCH collision, additional time d3 is needed (which results N2+d1+d3 in total cancellation time) for LP CG-PUSCH and HP DG-PUSCH collision resolution.
o
d3 = {0, 
}symbol(s)
upon UE capability report, where 
for
SCS=15/30/60/120kHz, respectively.
Agreement
The following TP to remove the restriction of disallowing the collision between HP SPS HARQ-ACK with LP PUCCH/PUSCH is endorsed for the editor’s CR on TS38.213.
|
------------------ Text Proposal for 38.213 Section 9 ------------------ A UE does not expect to be scheduled to transmit a PUCCH or a PUSCH with smaller priority index that would overlap in time with a PUCCH of larger priority index with HARQ-ACK information only in response to a PDSCH reception without a corresponding PDCCH unless the UE is provided UCI-MuxWithDifferentPriority. A UE does not expect to be scheduled to transmit a PUCCH of smaller priority index that would overlap in time with a PUSCH of larger priority index with SP-CSI report(s) without a corresponding PDCCH. |
R1-2200728 Summary#2 of email thread [107bis-e-R17-IIoT-URLLC-04] Moderator (OPPO)
From Jan 20th GTW session
Agreement
Support multiplexing of high-priority HARQ-ACK and low-priority HARQ-ACK on PUCCH Format 2.
· Extend legacy agreements on PRB number determination for Rel-17 (RAN1#106bis-e and RAN1#107-e) to cover PUCCH Format 2.
· Use the HP UCI bit number and HP RE number for ∆TF,b,f,c(i) formula selection and calculation (as for PUCCH formats 3 & 4).
· Concatenate the coded HP HARQ-ACK bits and the coded LP HARQ-ACK bits sequentially and apply the procedures described in R15 TS 38.211 to the concatenated coded HARQ-ACK bit sequence.
Agreement
When a PUCCH carrying HP SR and HP HARQ-ACK with PUCCH format 2/3/4 overlaps with a PUCCH carrying LP HARQ-ACK, information bits for K HP SRs are appended to HP HARQ-ACK bits, and treat them as HP UCI, where K (K≥1) PUCCHs semi-statically configured for K HP SRs overlap with the original PUCCH carrying the HP HARQ-ACK.
·
The number of HP UCI bits
is 
, same as
Rel-15;
o FFS: PF0, PF1
· Reuse other procedures for multiplexing of LP HARQ-ACK and HP HARQ-ACK on PUCCH resource with PF 2/3/4, i.e. separate coding, PRB determination, rate matching and power control.
· If the HP HARQ-ACK is a dynamic HARQ-ACK, a PUCCH resource indicated by PRI is used for multiplexing.
· If the HP HARQ-ACK is a SPS HARQ-ACK, a PUCCH resource determined from the PUCCH resource(s) provided by sps-PUCCH-AN-List is used for multiplexing.
Agreement
Introduce separate RRC parameters to configure ‘Multiplexing UCIs of different priorities on PUCCH or PUSCH’ in the primary and secondary PUCCH cell group.
Agreement
Define a new table for beta-offset values <1.
· FFS for the values with the starting point as below.
|
|
|
[0.8] |
|
[0.64] |
|
[0.5] |
|
[0.4] |
|
[0.32] |
|
[0.25] |
|
[0.2] |
|
[0.1] |
Decision: As per email decision posted on Jan 24th,
Agreement:
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a LP PUSCH in R17,
· If HP HARQ-ACK, LP HARQ-ACK, and LP CSI including a single part would be transmitted on LP PUSCH,
o Reuse Rel-15 HARQ-ACK rate matching/puncturing and RE mapping for HP HARQ-ACK.
o Reuse Rel-15 CSI part 1 rate matching and RE mapping for LP HARQ-ACK.
o Reuse Rel-15 CSI part 2 rate matching and RE mapping for the single part of LP CSI.”
Agreement:
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a HP PUSCH in R17,
· If HP HARQ-ACK, LP HARQ-ACK, and HP CSI including a single part would be transmitted on HP PUSCH,
o Reuse Rel-15 HARQ-ACK rate matching/puncturing and RE mapping for HP HARQ-ACK.
o Reuse Rel-15 CSI part 1 rate matching and RE mapping for the single part of HP CSI.
o Reuse Rel-15 CSI part 2 rate matching and RE mapping for LP HARQ-ACK.
R1-2200757 Summary#3 of email thread [107bis-e-R17-IIoT-URLLC-04] Moderator (OPPO)
From Jan 25th GTW session
Agreement
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a PUCCH in R17, when the total number of LP and HP HARQ-ACK bits is more than 2, for HP HARQ-ACK or LP HARQ-ACK of 1-2 bit(s), support separate coding
· Option 1: Reuse R15 TS 38.212 Clause 5.3.3.1 for 1-bit. Reuse R15 TS 38.212 Clause 5.3.3.2 for 2-bit. Apply the Rel-15 placeholder bit handling procedure for PUSCH together with Rel-15 PUCCH scrambling sequence.
Agreement
Introduce RRC parameters to enable the UE handling for overlapping CG/DG PUSCH of different priorities, i.e., keep the yellow marked related RRC parameters in rows 68 and 69 from the IIoT&URLLC RRC parameter sheet from R1-2112979.
Decision: As per email decision posted on Jan 26th,
Agreement
In R17, if HP HARQ-ACK, LP HARQ-ACK and HP CSI consisting of two parts would be transmitted on HP PUSCH,
· LP HARQ-ACK is dropped.
· Reuse R15 HARQ-ACK rate matching/puncturing and RE mapping for HP HARQ-ACK.
Final summary in R1-2200791.
Including any RAN1 involvement in propagation delay compensation enhancements (including mobility issues, if any) and CSI feedback enhancements.
R1-2200013 Discussion on propagation delay compensation enhancements New H3C Technologies Co., Ltd.
R1-2200019 On remaining issues of propagation delay compensation Nokia, Nokia Shanghai Bell
R1-2200110 Discussion on propagation delay compensation enhancements ZTE
R1-2200200 Remaining issues for propagation delay compensation enhancements Samsung
R1-2200345 Enhancement for support of time synchronization OPPO
R1-2200375 Remaining issues for RTT-based propagation delay compensation Intel Corporation
R1-2200677 Propagation Delay Compensation Enhancements for Time Synchronization Ericsson (rev of R1-2200443 - Late submission)
R1-2200574 Discussion on propagation delay compensation enhancements LG Electronics
R1-2200650 Enhancements for support of time synchronization Huawei, HiSilicon
[107bis-e-R17-IIoT-URLLC-05] – Chengyan (Huawei)
Email discussion on propagation delay compensation enhancements
- 1st check point: January 20
- Final check point: January 25
Decision: As per email decision posted on Jan 21st,
Conclusion
SRS for positioning is not supported for RTT-based PDC, regardless of whether TRS or PRS is used for RTT-based PDC.
Conclusion
Measurement gaps should not be mandatory for a UE to process PRS for PDC purposes.
Agreement:
Add dl-PRS-ResourceRepetitionFactor-r16 and dl-PRS-ResourceTimeGap-r16 in the RRC parameters list for RTT-based PDC
Agreement:
Include dl-PRS-ResourceBandwidth-r16 and dl-PRS-StartPRB-r16 in NR-DL-PRS-Resource-r16 for the PRS configuration for RTT-based PDC.
R1-2200756 Feature lead summary#1 on propagation delay compensation enhancements Moderator (Huawei)
From Jan 21st GTW session
Agreement
Add new “usage-pdc-r17” field to SRS-ResourceSet to indicate that this ResourceSet is used for PDC purpose, meanwhile also indicate that this ResourceSet is used for other purpose by usage.
Agreement
· Alt.2: No need to add new “pathlossReferenceRS-PDC-r17” field to SRS-ResourceSet to indicate a reference signal (e.g. a CSI-RS config or a SS block or a DL-PRS config) to be used for SRS path loss estimation.
o Note: With Alt.2, the existing RRC parameter PathlossReferenceRS-Config is used to indicate a reference signal (e.g. a CSI-RS config or a SS block) to be used for SRS path loss estimation.
Working Assumption
· Alt.1: Add new “spatialRelationInfo-PDC-r17” field to SRS-Resource to indicate the spatial relation between a reference RS and the target SRS, with spatialRelationInfo-PDC-r17 as below:
spatialRelationInfo-PDC-r17 ::= SEQUENCE {
referenceSignal CHOICE {
ssb-Index SSB-Index,
csi-RS-Index NZP-CSI-RS-ResourceId,
dl-PRS-PDC nr-DL-PRS-ResourceID-r16
srs SEQUENCE {
resourceId SRS-ResourceId,
uplinkBWP BWP-Id
}
}
}
Note: RAN1 does not pursue further optimization for SRS configuration with legacy usage and meanwhile with PRS as spatial relation source.
Decision: As per email decision posted on Jan 24th,
Conclusion
For PDC method based on legacy TA-based mechanism, the TA value for PDC is the timing advance value associated with the PTAG of MCG.
Agreement
"dl-PRS-PointA-r16" is not included for the PRS configuration for RTT-based PDC.
· Note: RAN1 specification change is expected
Decision: As per email decision posted on Jan 25th,
Agreement
“dl-PRS-ResourcePower-r16” from 37.355 is not included in the RRC parameters list for PRS configuration for RTT-based PDC.
Conclusion
There is no consensus to introduce new RRC parameter “DL-PRS-PDC-QCL-Info” to specify the QCL indication with other DL reference signals, for DL PRS configuration for PDC.
Final summary in R1-2200799.
R1-2200297 Remaining issues for CSI enhancement for IIOT and URLLC Qualcomm Incorporated
[107bis-e-R17-IIoT-URLLC-06] – Paul (InterDigital)
Email discussion on CSI feedback enhancements
- 1st check point: January 20
- Final check point: January 25
R1-2200755 Summary #1 of [107bis-e-R17-IIoT-URLLC-06] Email discussion on CSI feedback enhancements Moderator (InterDigital)
Decision: As per email decision posted on Jan 20st, there is no consensus to enhance omission rules in case 4-bits subband CQI is configured. Most companies think that this is an optimization that is too late to introduce and that would entail additional UE complexity and specification impact.
No further discussion on CSI feedback enhancements for eIIoT/URLLC is needed in RAN1#107b-e.
Please refer to RP-210854 for detailed scope of the WI.
Please also refer to section 5 of RP-212605 for additional guidance for this e-meeting.
[108-e-R17-RRC-IIoT-URLLC] – Klaus (Nokia)
Email discussion on Rel-17 RRC parameters for IIoT and URLLC
- 1st check point for first LS in [108-e-R17-RRC]: February 24
- Final check point for second LS in [108-e-R17-RRC] if necessary: March 3
R1-2202775 Summary of [108-e-R17-RRC-IIoT-URLLC] Email discussion on Rel-17 RRC parameters for IIoT and URLLC Moderator (Nokia)
Document is noted. For consolidation under 8 in [108-e-R17-RRC].
R1-2202776 List of agreements of Rel-17 URLLC/IIoT WI (post RAN1#108-e) WI rapporteur (Nokia)
R1-2200959 UE feedback enhancements for HARQ-ACK Huawei, HiSilicon
R1-2201002 HARQ-ACK Enhancements for IIoT/URLLC Ericsson
R1-2201017 HARQ-ACK Feedback Enhancements for URLLC/IIoT Nokia, Nokia Shanghai Bell
R1-2201021 Remaining issues for HARQ-ACK feedback enhancements New H3C Technologies Co., Ltd.
R1-2201090 Remaining issues on HARQ-ACK enhancements for Rel-17 URLLC vivo
R1-2201161 Discussion on HARQ-ACK enhancements for eURLLC ZTE
R1-2201295 HARQ-ACK enhancements for Rel-17 URLLC/IIoT OPPO
R1-2201356 UE feedback enhancements for HARQ-ACK CATT
R1-2201475 Discussion on HARQ-ACK feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
R1-2201544 Discussion on HARQ-ACK feedback enhancements for Rel-17 URLLC Spreadtrum Communications
R1-2201579 Remaining issues on HARQ-ACK enhancements for URLLC Sony
R1-2201599 UE feedback enhancements for HARQ-ACK CAICT
R1-2201608 Discussion on remaining issues on PUCCH carrier switching Panasonic
R1-2201611 UE feedback enhancements for HARQ-ACK ETRI
R1-2201693 Open issues on UE HARQ feedback enhancements Intel Corporation
R1-2201769 Remaining issues in UE feedback enhancements for HARQ-ACK Apple
R1-2201903 UE feedback enhancements for HARQ-ACK NEC
R1-2202009 Maintenance on HARQ-ACK feedback enhancements Samsung
R1-2202134 HARQ-ACK enhancement for IOT and URLLC Qualcomm Incorporated
R1-2202341 Discussion on UE feedback enhancement for HARQ-ACK LG Electronics
[108-e-R17-IIoT-URLLC-01] – Klaus (Nokia)
Email discussion on UE feedback enhancements for HARQ-ACK
- 1st check point: February 25
- Final check point: March 3
Decision: As per email decision posted on Feb 22nd,
Agreement
Joint operation between PUCCH repetition and Rel-17 enhanced Type 3 HARQ-ACK CB triggering is supported in Rel-17.
Agreement
For one-shot HARQ-ACK re-transmission on PUCCH, triggering the HARQ-ACK CB re-transmission with a triggering DCI with CRC scrambled with the CS-RNTI is not supported.
Agreement
Support joint operation of Rel-17 Intra-UE multiplexing and one-shot HARQ re-tx in Rel-17
Agreement
Support joint Operation of R17 Intra-UE multiplexing and semi-static PUCCH cell switching
· The Rel-17 Intra-UE multiplexing operation of step 1 and step 2 are performed using the determined target PUCCH cell based on the semi-static time domain pattern,
o i.e., once a target cell is determined based on the time-domain pattern due, the intra-UE multiplexing procedures can be applied to resolve collision in case of overlapping PUCCH resources on the target PUCCH cell.
Conclusion
When a UE receives a one-shot triggering DCI for HARQ-ACK re-transmission, and did not generate an HARQ-ACK codebook with the indicated PHY priority for corresponding PUCCH transmission in the original PUCCH slot, the UE ignores the triggering DCI, without determining corresponding PUCCH transmission in the PUCCH slot designated for HARQ-ACK re-transmission.
· No RAN1 specification impact
Conclusion
Semi-static PUCCH cell switching, i.e. the PUCCH cell determination based on the time-domain pattern, should be performed before UCI multiplexing/prioritization.
· No RAN1 specification impact
Decision: As per email decision posted on Feb 24th,
Agreement
For PUCCH cell switching, introduce a new RRC parameter in SPS-Config to allow configuring a separate ‘n1PUCCH-AN’ (i.e. PUCCH resource ID) for PUCCH sSCell for SPS HARQ operation.
R1-2201020 Moderator summary #1 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
From Feb 25th GTW session,
Agreement
The Rel-16 PHY prioritization operation and Rel-16 Type 3 with PHY priority operation & Rel-17 enhanced Type 3 HARQ-ACK CB with PHY priority operation is further clarified as:
· For Rel-17 enhanced Type 3 HARQ-ACK CB operation, the restriction on the Type 1 / Type 2 HARQ-ACK CB mapping from the earlier agreement below is only applicable to the same PHY priority of the Type 1 / Type 2 CB as the PUCCH for the enhanced Type 3 CB re-transmission. A LP PUCCH (or PUSCH) carrying the R17 enh. Type 3 CB is dropped according to the Rel-16 PHY prioritization procedures in case of an overlapping HP channel.
|
Agreement For the enhanced Type 3 HARQ-ACK CB of smaller size triggered in a PUCCH slot, the UE is not expecting HARQ-ACK information in a Type 1 or Type 2 HARQ-ACK CB to be transmitted that cannot be mapped to the enhanced Type 3 HARQ-ACK CB of smaller size as the HARQ process is not part of the codebook. |
· For Rel-16 Type HARQ-ACK 3 HARQ-ACK CB operation, the UE creates the Rel-16 Type 3 HARQ-ACK CB for transmission on a PUCCH of the indicated priority. A LP PUCCH (or PUSCH) carrying the R16 Type 3 HARQ-ACK CB is dropped according to the Rel-16 PHY prioritization procedures in case of an overlapping HP channel.
Proposal:
Support joint operation of PUCCH repetition and dynamic PUCCH carrier switching in Rel-17.
· The PUCCH cell indication in the DCI scheduling the PUCCH is applicable for all the PUCCH repetitions.
Objected by Samsung
Agreement
For SPS HARQ-ACK deferral, a UE is not expecting to be configured with both, SPS HARQ deferral for any of the SPS configurations of a PHY priority, and PUCCH repetitions for any PUCCH resource of the same PHY priority.
Decision: As per email decision posted on Feb 28th,
Agreement
The following TP to 38.213 is endorsed for the editor’s CR:
|
9.2.5.4 UE procedure for deferring HARQ-ACK for SPS PDSCH … -
the second HARQ-ACK information bits, generated as described in clause 9.1.2,
are appended in a HARQ-ACK codebook the UE generates as described in clauses
9.1.2, 9.1.2.1, - if the UE would receive a PDSCH providing a TB for a same HARQ process as a HARQ-ACK information bit from the second HARQ-ACK information bits prior to transmitting the PUCCH or the PUSCH, the UE does not include the HARQ-ACK information bit in the HARQ-ACK information bits. |
Agreement
The following TP to 38.213 is endorsed for the editor’s CR:
|
9.2.5.4 UE procedure for deferring HARQ-ACK for SPS PDSCH If a UE is provided spsHARQdeferral and, after performing the procedures in clauses 9 and 9.2.5 to resolve overlapping among PUCCHs and PUSCHs in a first slot if any, the UE determines a PUCCH resource for a PUCCH transmission with first HARQ-ACK information bits for SPS PDSCH receptions that the UE would report for a first time, and the PUCCH resource - is provided by SPS-PUCCH-AN-List as described in clause 9.2.1, or by n1PUCCH-AN if SPS-PUCCH-AN-List is not provided - overlaps with a symbol indicated as downlink by tdd-UL-DL-ConfigurationCommon or tdd-UL-DL-ConfigDedicated, or indicated for a SS/PBCH block by ssb-PositionsInBurst, or belonging to a CORESET associated with a Type0-PDCCH CSS set the UE - determines an earliest second slot and, after performing the procedures in clauses 9 and 9.2.5 to resolve overlapping among PUCCHs and PUSCHs if any, a PUSCH or a PUCCH in the earliest second slot to multiplex HARQ-ACK information bits that include second HARQ-ACK information bits from the first HARQ-ACK information bits ... |
Decision: As per email decision posted on Mar 2nd,
Agreement
Support joint operation of R17 Intra-UE multiplexing and enhanced Type 3 HARQ-ACK CB in Rel-17, based on the following operational details of Alt. 1:
· The UE is not expecting HARQ-ACK information in a Type 1 or Type 2 HARQ-ACK CB with the same priority index (i.e. in step 1) as the enhanced Type 3 HARQ-ACK CB to be transmitted that cannot be mapped to the enhanced Type 3 HARQ-ACK CB. The UE performs Rel-17 Intra-UE multiplexing in step 2 as defined.
· For Rel-16 Type 3 CB, the UE creates the Rel-16 Type 3 CB with a PUCCH based on the indicated priority in step 1, and performs step 2 of the Rel-17 Intra-UE multiplexing of potential HARQ-ACK of different priority afterwards.
Decision: As per email decision posted on Mar 3rd,
For the 38.213 editor:
The following text proposal made in reference to the post-RAN1#107b-e draft CR was deemed technically correct by RAN1. Please consider them in the next specification revision.
|
9.1.5 HARQ-ACK codebook retransmission …. If
in slot |
R1-2202773 Moderator summary #2 on HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
From Mar 3rd GTW session
Agreement
For dynamic PUCCH cell switching and Rel-16 PHY prioritization (if any), the earlier RAN1 conclusion is updated with the following changes in red
|
Conclusion For dynamic PUCCH cell switching, the UE does not expect a PUCCH slot with UCI of a certain PHY priority on PCell /SPCell / PUCCH SCell to overlap with a PUCCH slot with HARQ-ACK of the same or different PHY priority on the dynamically indicated alternative PUCCH cell.
|
Conclusion
There is no consensus in RAN1 to support joint operation of Rel-17 Intra-UE multiplexing and SPS HARQ deferral in Rel-17.
Conclusion
There is no consensus in RAN1 to support joint operation of Rel-17 Intra-UE multiplexing and dynamic PUCCH cell switching in Rel-17.
Final summary in R1-2202774.
R1-2200961 Uplink enhancements for URLLC in unlicensed controlled environments Huawei, HiSilicon
R1-2201022 Remaining issues on enhancements for unlicensed band URLLC/IIoT New H3C Technologies Co., Ltd.
R1-2201401 Discussion on unlicensed band URLLC/IIoT ZTE Corporation
R1-2201694 Remaining Clarifications to Enable URLLC/IIoT in Unlicensed Band Intel Corporation
R1-2202135 Uplink enhancements for URLLC in unlicensed controlled environments Qualcomm Incorporated
R1-2202363 Remaining issues on enhancements for unlicensed band URLLC/IIoT NEC
[108-e-R17-IIoT-URLLC-02] – Sorour (Ericsson)
Email discussion on unlicensed band URLLC/IIoT
- 1st check point: February 25
- Final check point: March 3
R1-2202536 Summary#1 - Enhancements for IIOT/URLLC on Unlicensed Band Moderator (Ericsson)
Decision: As per email decision posted on Feb 23rd,
Agreement
The text proposal in Proposal 1-1 of R1-2202536 is agreed for the editor’s CR on TS 37.213 (Clause 4.3.1.2.4.1).
Agreement
The text proposal in Proposal 1-2 of R1-2202536 is agreed for the editor’s CR on TS 37.213 (Clause 4.3.1.2.4.2).
Conclusion
In semi-static channel access mode, for a transmission burst that includes scheduled and configured UL transmissions, conclude that no specification changes are needed to ensure that the associated COT-ownership for all transmissions in the transmission burst is the same, and it can be handled by gNB proper scheduling and proper UE implementation.
Final summary in R1-2202537.
R1-2200960 Intra-UE multiplexing enhancements Huawei, HiSilicon
R1-2201003 Intra-UE Multiplexing/Prioritization Enhancements for IIoT/URLLC Ericsson
R1-2201018 On UL intra-UE prioritization and multiplexing enhancements Nokia, Nokia Shanghai Bell
R1-2201023 Intra-UE multiplexing and prioritization New H3C Technologies Co., Ltd.
R1-2201091 Remaining issues on intra-UE Multiplexing/Prioritization for Rel-17 URLLC vivo
R1-2201162 Discussion on enhanced intra-UE multiplexing ZTE
R1-2201296 Enhancements on intra-UE multiplexing/prioritization OPPO
R1-2201357 Intra-UE multiplexing and prioritization CATT
R1-2201379 Discussion on intra-UE multiplexing with different priorities Panasonic Corporation
R1-2201439 Discussion on remaining issue for intra-UE multiplexing China Telecom
R1-2201476 Discussion on intra-UE multiplexing/prioritization for Rel.17 URLLC NTT DOCOMO, INC.
R1-2201545 Discussion on intra-UE multiplexing/prioritization Spreadtrum Communications
R1-2201580 Remaining issues on intra-UE multiplexing & prioritisation Sony
R1-2201612 Intra-UE Multiplexing/Prioritization ETRI
R1-2201654 Intra-UE multiplexing and prioritization InterDigital, Inc.
R1-2201695 Remaining Open Details of Intra-UE Uplink Channel Multiplexing and Prioritization Intel Corporation
R1-2201770 Views on Intra-UE Multiplexing/Prioritization Apple
R1-2201904 Discussion on Intra-UE prioritization and multiplexing NEC
R1-2202010 Maintenance on Intra-UE Multiplexing/Prioritization Samsung
R1-2202093 Intra-UE multiplexing enhancement for IIoT/URLLC Lenovo
R1-2202136 Intra-UE multiplexing and prioritization for IOT and URLLC Qualcomm Incorporated
R1-2202191 Channel collision handling and intra-UE UCI multiplexing with different priorities Sharp
R1-2202243 Discussion on intra-UE multiplexing and prioritization ITRI
R1-2202342 Discussion on Intra-UE multiplexing/prioritization LG Electronics
R1-2202485 Remaining issues on intra-UE multiplexing/prioritization for URLLC/IIoT WILUS Inc.
[108-e-R17-IIoT-URLLC-03] – Yanping (CATT)
Email discussion on intra-UE multiplexing/prioritization
- Focus on simultaneous TX of PUCCH/PUSCH and multiplexing/overlapping resolution procedure for intra-UE multiplexing of UCI of different priorities on PUCCH and PUSCH (Capability 1 only)
- 1st check point: February 25
- Final check point: March 3
R1-2202575 Summary #1 of email thread [108-e-R17-IIoT-URLLC-03] Moderator (CATT)
From Feb 21st GTW session
Agreement
For resolving collision of PUCCHs of different priorities without repetition within a time unit, down-select from the following options:
FFS: Details on time units for all options
Agreement
The following working assumption is now confirmed:
For resolving collision of PUCCHs of different priorities without repetition within a time unit, the time unit of HP HARQ-ACK is used.
Agreement
To resolve overlapping between a HP PUCCH carrying HARQ-ACK only and a LP PUCCH carrying HARQ-ACK and CSI/SR, only LP HARQ-ACK is multiplexed with HP HARQ-ACK and LP CSI/SR are dropped.
· FFS: The Rel-15 timeline is applied for all the overlapping channels before step 1
Agreement
To resolve overlapping between a HP PUCCH carrying positive SR only and a LP PUCCH carrying HARQ-ACK and CSI and/or SR, LP PUCCH with PF2/3/4 is dropped.
· FFS LP PUCCH carrying LP HARQ-ACK and LP SR with PF 0/1
Agreement
To resolve overlapping between a HP PUSCH with or without HP UCI and a LP PUCCH carrying HARQ-ACK and CSI/SR, only LP HARQ-ACK is multiplexed in HP PUSCH and LP CSI/SR are dropped.
· FFS: The Rel-15 timeline is applied for all the overlapping channels before step 1
Agreement
For Rel-17 intra-UE multiplexing, PUCCH and PUSCH cancellation due to dynamic SFI, semi-static DL symbols and SSB symbols are performed after step 2 of Rel-17 intra-UE multiplexing.
Agreement
The same time unit is used for resolving collision of PUCCHs of different priorities with and without repetition.
Agreement
For resolving collision of overlapping PUCCHs and PUSCHs of different priorities in Step 2.2,
· If a LP PUSCH overlaps with a HP PUCCH with repetitions, the LP PUSCH is dropped before multiplexing with HP HARQ-ACK if any.
· If a HP PUSCH overlaps with a LP PUCCH with repetitions, the LP PUCCH is dropped.
Agreement
Confirm the following working assumption in RAN1#107bis-e with the following update (in RED):
For resolving collision of PUCCHs and PUSCHs of different priorities in step 2.2, LP PUSCH(s) overlapping with HP PUCCH resource which carries at least positive HP SR are dropped before UCI multiplexing.
· Step 1.2 behavior is not affected by the above
Decision: As per email decision posted on Feb 23rd,
Conclusion
If UCI-MuxWithDifferentPriority or UCI-MuxWithDifferentPriority-secondaryPUCCHgroup is enabled for a cell group, it is not expected that MAC PDUs are delivered for two overlapping CG PUSCHs of different PHY priorities on a serving cell within the same cell group.
R1-2202707 Summary #2 of email thread [108-e-R17-IIoT-URLLC-03] Moderator (CATT)
From Feb 25th GTW session
Agreement
For resolving collision of PUCCHs of different priorities without repetition within a time unit, Option 1 is adopted.
· Option 1:
o The reference PUCCH resource is determined as in Rel-15, i.e. based on the starting symbol and duration
o In step 2.1-2, select up to one PUCCH resource overlapping with the reference PUCCH resource according to Rel-15 pseudo code
Decision: As per email decision posted on Feb 28th,
Agreement
To resolve overlapping between a HP PUCCH carrying positive SR only and a LP PUCCH carrying LP HARQ-ACK and LP SR with PF 0/1, LP PUCCH is dropped.
Agreement
When Rel-17 intra-UE multiplexing is enabled by UCI-MuxWithDifferentPriority or UCI-MuxWithDifferentPriority-secondaryPUCCHgroup, the Rel-15 timeline is applied for all the overlapping channels (regardless of their priorities) before step 1.
Decision: As per email decision posted on Mar 1st,
Agreement
To resolve overlapping between a HP PUCCH carrying SR and HP HARQ-ACK with PUCCH format 2/3/4 and a LP PUCCH carrying HARQ-ACK and CSI/SR, only LP HARQ-ACK is multiplexed with HP UCI (i.e., SR and HARQ-ACK) and LP CSI/SR are dropped.
· FFS HP PUCCH with PUCCH format 0/1
R1-2202770 Summary #3 of email thread [108-e-R17-IIoT-URLLC-03] Moderator (CATT)
From Mar 1st GTW session
Agreement
For resolving collision of overlapping PUCCHs of different priorities in Step 2.1, resolve collision of PUCCHs with repetitions before resolving collision of PUCCHs without repetitions. After resolving collision of PUCCHs without repetition, it is not expected that a PUCCH would overlap with another PUCCH with repetition.
· Note: A PUCCH without repetitions not overlapping with any other PUCCH with repetitions is not considered into the above collision resolving of PUCCHs with repetitions
Agreement
For resolving collision of overlapping PUCCHs of different priorities with repetition in Step 2.1 where at least one of the overlapping PUCCHs is subject to repetition, LP PUCCH overlapping with HP PUCCH is dropped if any overlapping PUCCH is subject to repetition.
Agreement
For resolving collision of overlapping PUCCHs of different priorities without repetition in Step 2.1, a LP PUCCH is associated with the first overlapping time unit of HP HARQ-ACK. For a subsequent overlapping time unit of HP HARQ-ACK if any, the LP PUCCH is associated with the time unit if the LP PUCCH is not determined to be dropped or multiplexed with other channels in previous overlapping time unit(s).
· Note: Rel-15 timeline is applied for all the overlapping channels (regardless of their priorities) in a group of overlapping channels within a slot before step 1
[108-e-R17-IIoT-URLLC-04] – Jia (OPPO)
Email discussion on intra-UE multiplexing/prioritization
- Focus on PHY prioritization of overlapping DG-PUSCH/CG-PUSCH and remaining details on intra-UE multiplexing of UCI of different priorities on PUCCH and PUSCH (except multiplexing/overlapping resolution procedure)
- 1st check point: February 25
- Final check point: March 3
Decision: As per email decision posted on Feb 23rd,
Agreement
For the scenario where a PUCCH carrying high-priority HARQ-ACK overlaps with another PUCCH carrying low-priority HARQ-ACK and the total payload size is two bits, the order of the multiplexed two bits is:
· high-priority HARQ-ACK bit, low-priority HARQ-ACK bit.
Agreement
If HP HARQ-ACK without LP HARQ-ACK would be transmitted on LP PUSCH, the HP HARQ-ACK should be multiplexed on the LP PUSCH by reusing the rate matching/puncturing and RE mapping for the legacy HARQ-ACK.
Conclusion
For multiplexing a high-priority (HP) HARQ-ACK and a low-priority (LP) HARQ-ACK into a PUSCH in R17, reuse the same power control formula as in Rel-15.
· No specification impacts.
R1-2202584 Summary#1 of email thread [108-e-R17-IIoT-URLLC-04] Moderator (OPPO)
From Feb 23rd GTW session
Agreement
When a PUCCH carrying HP SR with PF0/1 overlaps with a PUCCH carrying LP HARQ-ACK with PF0/1, the LP HARQ ACK is dropped when colliding with positive SR
To be revisited: Focus on the following two options
If LP HARQ-ACK without HP HARQ-ACK would be transmitted on HP PUSCH, down-select from the options:
· Option 1: The LP HARQ-ACK should be multiplexed on the HP PUSCH by reusing the rate matching/puncturing and RE mapping for the legacy HARQ-ACK.”
· Huawei/Hisi, ZTE, Sony, DOCOMO, ITRI, CATT, Panasonic, CTC, QC, Ericsson
· Option 2: UE follows the same behaviour as that in case of PUSCH with HP HARQ-ACK.
· Nokia/NSB, OPPO, LG, Apple, Sharp, Spreadtrum, New H3C, Lenovo, Samsung (can live with it)
Agreement
The values for beta-offset values <1 are:
|
|
|
0.6 |
|
0.4 |
|
0.2 |
|
0.1 |
|
0.05 |
· They are mapped to indices 16-20 in the table.
· These values are used in addition to the legacy values in indices 0-15.
R1-2202644 Summary#2 of email thread [108-e-R17-IIoT-URLLC-04] Moderator (OPPO)
From Mar 1st GTW session
Agreement
If LP HARQ-ACK without HP HARQ-ACK would be transmitted on HP PUSCH,
· Option 2: UE follows the same behaviour as that in case of PUSCH with HP HARQ-ACK assuming two bits
o FFS for CG-UCI PUSCH.
R1-2202830 Summary#3 of email thread [108-e-R17-IIoT-URLLC-04] Moderator (OPPO)
From Mar 3rd GTW session
Conclusion
There is no consensus in RAN1 to introduce specification support to address the ambiguity on LP HARQ-ACK type-1 codebook existence or LP HARQ-ACK type-2 codebook size due to DCI mis-detection.
Including any RAN1 involvement in propagation delay compensation enhancements (including mobility issues, if any) and CSI feedback enhancements.
R1-2201004 Propagation Delay Compensation Enhancements for Time Synchronization Ericsson
R1-2201019 On remaining issues of propagation delay compensation Nokia, Nokia Shanghai Bell
R1-2201024 Discussion on propagation delay compensation enhancements New H3C Technologies Co., Ltd.
R1-2201163 Discussion on propagation delay compensation enhancements ZTE
R1-2201297 Remaining issues for PDC OPPO
R1-2201696 Open issues for RTT-based propagation delay compensation Intel Corporation
R1-2202343 Discussion on propagation delay compensation enhancements LG Electronics
R1-2202438 Enhancements for support of time synchronization Huawei, HiSilicon
[108-e-R17-IIoT-URLLC-05] – Chengyan (Huawei)
Email discussion on propagation delay compensation enhancements
- 1st check point: February 25
- Final check point: March 3
R1-2202571 Feature lead summary#1 on propagation delay compensation enhancements Moderator (Huawei)
Decision: As per email decision posted on Feb 23rd,
Agreement
Do not include dl-PRS-ID for the PRS configuration for RTT-based PDC.
· Detailed clarification(s) for the exception handling in TS 38.214 are up to the editor.
Agreement
Do not include NR-DL-PRS-SFN0-Offset for the PRS configuration for RTT-based PDC.
· Detailed clarification(s) for the exception handling in TS 38.214 if necessary are up to the editor.
Agreement
Clarify in TS 38.214 that dl-PRS-CombSizeN-AndReOffset is used instead of dl-PRS-CombSizeN for the PRS reception for PDC.
· Detailed change(s) are up to TS 38.214 editor.
Decision: As per email decision posted on Feb 25th,
Conclusion
Do not support any modification to the existing MAC CE(s) for spatial relationship derivation for SRS in Rel-17 IIoT/eURLLC WI, regardless of whether the working assumption on spatial relationship for SRS is confirmed or not.
Agreement
For PDC purpose, the UE is not expected to measure DL PRS outside the active BWP.
Agreement
Do not include dl-PRS-SubcarrierSpacing and dl-PRS-CyclicPrefix for the PRS configuration for RTT-based PDC.
· PDC PRS share the same subcarrier spacing and cyclic prefix as the downlink active BWP of the serving cell. Detailed spec change(s) are up to editor(s).
Agreement
UE does not expect to be configured with different dl-PRS-StartPRB-r16 or different dl-PRS-ResourceBandwidth-r16 for any two PDC PRS resources.
Conclusion
No need to include time stamp in the measurement report of Rx-Tx time difference for PDC.
R1-2202572 Feature lead summary#2 on propagation delay compensation enhancements Moderator (Huawei)
R1-2202812 Feature lead summary#3 on propagation delay compensation enhancements Moderator (Huawei)
Decision: As per email decision posted on Mar 1st,
Agreement
For RTT-based PDC, the UE is expected to receive PRS only in RRC_CONNECTED mode.
· Spec change if any is up to the editor
Agreement
The following text proposal is endorsed for the editor’s CR on TS 38.211.
|
---------------------------------Start of Text Proposal to TS 38.211 v17.0.0----------------------- 7.4.1.7.3 Mapping to physical resources in a downlink PRS resource For each
downlink PRS resource configured, the UE shall assume the sequence <Unchanged parts are omitted> If
the downlink PRS resource is configured for RTT based propagation delay
compensation as described in clause 9 of [6, TS 38.214], the reference point
for < Unchanged parts are omitted > --------------------------------- End of Text Proposal to TS 38.211 v17.0.0----------------------- |
Agreement
Update the description for dl-PRS-StartPRB-r16 as highlight in Red below:
· This field specifies the start PRB index defined as offset with respect to subcarrier 0 in common resource block 0.
Agreement
The following text proposal is endorsed for the editor’s CR on TS 38.211.
|
---------------------------------Start of Text Proposal to TS 38.211 v17.0.0----------------------- 7.4.1.7.3 Mapping to physical resources in a downlink PRS resource For each downlink PRS
resource configured, the UE shall assume the sequence <Unchanged parts are omitted> - the comb size <Unchanged parts are omitted> 7.4.1.7.4 Mapping to slots in a downlink PRS resource set For a downlink PRS resource in a downlink PRS resource set, the UE shall assume the downlink PRS resource being transmitted when the slot and frame numbers fulfil <Unchanged parts are omitted> For a downlink PRS resource in a downlink PRS resource set configured for RTT-based propagation delay compensation, the UE shall assume the downlink PRS resource being transmitted as described in clause 9 of [6, TS 38.214]; otherwise, the UE shall assume the downlink PRS resource being transmitted as described in clause 5.1.6.5 of [6, TS 38.214]. < Unchanged parts are omitted > --------------------------------- End of Text Proposal to TS 38.211 v17.0.0----------------------- |
R1-2202813 Feature lead summary#4 on propagation delay compensation enhancements Moderator (Huawei)
From Mar 3rd GTW session
Agreement
The following working assumption made in RAN1#107b-e is confirmed with modification in BLUE/RED:
|
Working Assumption Alt.1: Add new “spatialRelationInfo-PDC-r17” field to SRS-Resource to indicate the spatial relation between a reference RS and the target SRS, with spatialRelationInfo-PDC-r17 as below: spatialRelationInfo-PDC-r17 ::= SEQUENCE { referenceSignal CHOICE { ssb-Index SSB-Index, csi-RS-Index NZP-CSI-RS-ResourceId, dl-PRS-PDC nr-DL-PRS-ResourceID-r16 srs SEQUENCE { resourceId SRS-ResourceId, uplinkBWP BWP-Id } } } Note: RAN1 does not pursue further optimization for SRS configuration with legacy usage and meanwhile with PRS as spatial relation source. Note 1: spatialRelationInfo-PDC-r17 is present in case of resourceType=periodic and usage-pdc-r17=True in the SRS-ResourceSet, otherwise the field is absent. (Note 1 will be reflected in the RRC parameter design and the spec changes if any are up to editor). Note 2: UE doesn’t expect to be configured with DL PRS for PDC as the spatial relation reference signal of SRS for PDC, if DL PRS for PDC is not configured for the UE Note 3: It is not intended to change the MIMO framework due to allowing DL PRS for PDC as one of the candidate spatial relation reference signals for SRS for PDC. It is up to gNB implementation to ensure appropriate configuration(s). - UE does not expect to be configured with SRS that has PRS as spatial relation source RS and meanwhile is the spatial relation source RS for other uplink channel(s)/signal(s). No specification change is needed. Note 4: Whether/how to update FG 25-19a can be further discussed in UE feature session, e.g. add either a new component under FG 25-19a or a new FG to enable UE capability reporting for the support of DL PRS for PDC as the spatial relation reference signal for periodic SRS for PDC. |
Agreement
For a UE configured with DL PRS for RTT-based PDC, the UE doesn't expect to be configured/scheduled to receive any other DL channel/signal in the PRBs that overlap those of the DL PRS for PDC in the OFDM symbols occupied by the DL PRS for PDC.
· Spec change(s) if any is up to the editor
Final summary in R1-2202932.
R1-2205143 Preparatory phase FL summary for HARQ-ACK feedback enhancements for URLLC/IIoT operation [109-e-Prep-AI8.3 R17 URLLC/IIoT] Moderator (Nokia)
R1-2203072 UE feedback enhancements for HARQ-ACK Huawei, HiSilicon
R1-2203188 Discussion on HARQ-ACK enhancements for eURLLC ZTE
R1-2203212 Remaining issues for HARQ-ACK feedback enhancements New H3C Technologies Co., Ltd.
R1-2203273 Maintenance of Rel-17 HARQ-ACK Feedback Enhancements for URLLC/IIoT Nokia, Nokia Shanghai Bell
R1-2203304 Discussion on HARQ-ACK feedback enhancements for Rel-17 URLLC Spreadtrum Communications
R1-2203397 Remaining Issues of HARQ-ACK Enhancements for IIoT/URLLC Ericsson
R1-2203434 Maintenance on UE feedback enhancements for HARQ-ACK CATT
R1-2203513 Remaining issues on HARQ-ACK enhancements for Rel-17 URLLC vivo
R1-2203680 Remaining issues of HARQ-ACK feedback enhancements for IIoT/URLLC NEC
R1-2203862 Maintenance on HARQ-ACK feedback enhancements Samsung
R1-2204002 Remaining issues on HARQ-ACK enhancements OPPO
R1-2204191 Remaining issues for HARQ-ACK codebook regarding PUCCH-sSCell ASUSTeK
R1-2204205 Remaining issues in HARQ-ACK feedback enhancements Apple
R1-2204343 Remaining issues on HARQ-ACK feedback enhancements for Rel.17 URLLC NTT DOCOMO, INC.
R1-2204616 Remaining issues on HARQ-ACK feedback enhancements LG Electronics
R1-2204725 Remaining issues for UE feedback enhancements for HARQ-ACK MediaTek Inc.
R1-2204982 Remaining issues on HARQ-ACK enhancement for IOT and URLLC Qualcomm Incorporated
[109-e-R17-IIoT-URLLC-01] – Klaus (Nokia)
Email discussion on UE feedback enhancements for HARQ-ACK (issues captured in R1-2205143) by May 18
- PUCCH_switch#1 (PUCCH repetition for semi-static PUCCH cell switching)
- PUCCH_switch#2 (PUCCH repetition for dynamic PUCCH cell switching)
- PUCCH_switch#3 (SPS HARQ and dynamic PUCCH cell switching)
- PUCCH_switch#5 (Correction for dynamic PUCCH cell switching based on restrictions)
- PUCCH_switch#9 (Type 1 HARQ-ACK CB with UL BWP change on PUCCH-sSCell)
- PUCCH_switch#10 (Overlapping slot clarification for semi-static PUCCH cell switching)
- PUCCH_switch#11 (Timing for semi-static PUCCH cell switching with SCell activation/deactivation/dormancy)
- PUCCH_switch#12 (SR/CSI operation with semi-static PUCCH cell switching)
- SPSdef#1 (Timeline for Dropping Deferred SPS HARQ)
- eType3#2 (Enh. Type 3 CB construction with per cell and per HARQ process configuration)
- eType3#3 (DCI field correction for Enh. Type 3CB)
- HARQretx#1 (One-shot HARQ-ACK retransmission and multi-DCI based multi-TRP)
- HARQretx#3 (C-RNTI for one-shot HARQ-ACK retx triggering)
- Other#1 (Correction to SPS HARQ timing with sub-slot PUCCH)
- 1st check point on May 12 and final check point on May 18
R1-2205144 Moderator summary #1 on [109-e-R17-IIoT-URLLC-01] UE feedback enhancements for HARQ-ACK Moderator (Nokia)
From May 10th GTW session
Discussion on both proposals for semi-static PUCCH cell switching (Option 2 (i.e. Alt. 2A) and Option 3 (i.e. Backup plan Alt. 3) as in section 2.1.3 of R1-2205144) : both objected by Samsung
R1-2205304 Moderator summary #2 on [109-e-R17-IIoT-URLLC-01] UE feedback enhancements for HARQ-ACK Moderator (Nokia)
Decision: As per email decision posted on May 11th,
Agreement
· Adopt the TP in Sec. 2.11.2 of R1-2205304 to 38.213 Sec. 9.1.4, v17.1.0 for the editor’s CR
· Adopt the TP in Sec. 2.14.2 of R1-2205304 to 38.213 Sec. 9.2.3, v17.1.0 for the editor’s CR
· The RRC parameter description for the RRC parameter pdsch-HARQ-ACK-enhType3DCIfield in the RAN1 RRC parameter sheet for Rel-17 URLLC/IIoT is updated as follows:
|
pdsch-HARQ-ACK-enhType3DCIfield |
Enables
the enhanced Type 3 CB through a new DCI field to indicate the enhanced Type
3 HARQ-ACK codebook in the primary |
Decision: As per email decision posted on May 13th,
Conclusion:
For PUCCH repetition and dynamic PUCCH carrier switching, the PUCCH cell indication in the DCI scheduling the PUCCH is applicable for all the PUCCH repetitions.
· Note: This behavior is captured in the existing specifications in 38.213 already
Agreement
For dynamic PUCCH cell switching, the SPS HARQ-ACK is always transmitted on Pcell/PScell/PUCCH-SCell.
· FFS: whether to define error case or related UE behavior.
Agreement
· Adopt the TP in Sec. 2.12.3 of R1-2205304 to 38.213 Sec. 9.1.5 for the editor’s CR.
R1-2205305 Moderator summary #3 on [109-e-R17-IIoT-URLLC-01] UE feedback enhancements for HARQ-ACK Moderator (Nokia)
Decision: As per email decision posted on May 16th,
Agreement
· Adopt the TP in Sec. 2.5.3 of R1-2205305 to 38.213 for the editor’s CR.
· Adopt the TP in Sec. 2.10.3 of R1-2205305 to 38.213 for the editor’s CR.
R1-2205445 Moderator summary #4 on [109-e-R17-IIoT-URLLC-01] UE feedback enhancements for HARQ-ACK Moderator (Nokia)
Decision: As per email decision posted on May 18th,
Agreement
· Adopt the TP in Sec. 2.3.7 of R1-2205445 to 38.213 for the editor’s CR.
· Adopt the TP in Sec. 2.4.5 of R1-2205445 to 38.213 for the editor’s CR.
· Adopt the TP in Sec. 2.8.4 of R1-2205446 to 38.213 for the editor’s CR.
· Adopt the TP in Sec. 2.16.2 of R1-2205445 to 38.213 for the editor’s CR.
R1-2205446 Moderator summary #5 on [109-e-R17-IIoT-URLLC-01] UE feedback enhancements for HARQ-ACK Moderator (Nokia)
R1-2205505 Updated RRC parameter sheet for Rel-17 URLLC / IIoT Moderator (Nokia)
Decision: As per email decision posted on May 20th, the updated higher layer parameters for Rel-17 URLLC & IIoT in R1-2205505 is endorsed.
R1-2205506 [Draft] LS on Rel-17 URLLC/IIoT RRC parameter updates Moderator (Nokia)
Decision: As per email decision posted on May 20th, the draft LS is endorsed. Final version is approved in R1-2205507.
Agreement
For semi-static PUCCH cell switch and PUCCH repetitions:
· Semi-static PUCCH cell switching is applicable only to PUCCH transmissions without repetitions.
· Conclusion: PUCCH repetitions are only applicable on Pcell, PScell, and PUCCH Scell.
Final summary in R1-2205504.
R1-2205146 Preparation phase FL summary for Rel-17 URLLC/IIoT intra-UE MUX A Moderator (CATT)
R1-2205189 Preparation phase summary of maintenance on Rel-17 Intra-UE Multiplexing/Prioritization - B Moderator (OPPO)
R1-2203073 Intra-UE multiplexing enhancements Huawei, HiSilicon
R1-2203189 Discussion on enhanced intra-UE multiplexing ZTE
R1-2203213 Remaining issue on intra-UE multiplexing and prioritization New H3C Technologies Co., Ltd.
R1-2203274 Maintenance of Rel-17 URLLC / IIoT Intra-UE Multiplexing/Prioritization Nokia, Nokia Shanghai Bell
R1-2203305 Discussion on intra-UE multiplexing/prioritization Spreadtrum Communications
R1-2203398 Remaining Issues of Intra-UE Multiplexing/Prioritization for IIoT/URLLC Ericsson
R1-2203435 Maintenance on intra-UE multiplexing and prioritization CATT
R1-2203514 Remaining issues on intra-UE Multiplexing/Prioritization for Rel-17 URLLC vivo
R1-2203863 Maintenance on Intra-UE Multiplexing/Prioritization Samsung
R1-2204003 Remaining issues on intra-UE multiplexing/prioritization OPPO
R1-2204091 Remaining issues of Intra-UE Multiplexing/Prioritization InterDigital, Inc.
R1-2204206 Remaining issues in intra-UE multiplexing/prioritization Apple
R1-2204344 Remaining issues on intra-UE multiplexing/prioritization for Rel.17 URLLC NTT DOCOMO, INC.
R1-2204439 Remaining details on intra-UE multiplexing and prioritization ITRI
R1-2204547 Remaining issues on intra-UE multiplexing/prioritization for URLLC/IIoT WILUS Inc.
R1-2204617 Remaining issues on Intra-UE multiplexing enhancements LG Electronics
R1-2204647 Intra-UE Multiplexing/Prioritization ETRI
R1-2204770 Remaining issue for Intra-UE Uplink Channel Multiplexing and Prioritization Intel Corporation
R1-2204983 Remaining issues on Intra-UE multiplexing and prioritization for IOT and URLLC Qualcomm Incorporated
[109-e-R17-IIoT-URLLC-02] – Yanping (CATT)
Email discussion on intra-UE multiplexing/prioritization A by May 18
- Issue 1: power allocation order
- Issue 2: Joint operation of R17 intra-UE multiplexing and UL CI
- Issue 10: Step 2 considers resultant PUCCH/PUSCH after step 1 only
- 1st check point on May 12 and final check point on May 18
R1-2205147 Summary #1 of email thread [109-e-R17-IIoT-URLLC-02] Moderator (CATT)
Decision: As per email decision posted on May 13th,
Agreement
Update the transmission power allocation order for Rel-17 if UE is configured with UCI-MuxWithDifferentPriority:
· LP PUSCH with HP HARQ-ACK should be of the same priority as HP PUSCH with HP HARQ-ACK, i.e., higher than HP PUSCH with CSI, as well as HP PUSCH only.
· HP PUSCH with LP HARQ-ACK only should have the same priority as HP PUSCH without UCI, i.e., lower than HP PUSCH with HP HARQ-ACK, as well as HP PUSCH with CSI.
Conclusion:
A UE can be configured with both UCI-MuxWithDifferentPriority and UplinkCancellation.
· No special handling for LP PUSCH multiplexed with HP UCI
R1-2205360 Summary #2 of email thread [109-e-R17-IIoT-URLLC-02] Moderator (CATT)
From May 18th GTW session
Agreement
For resolving collision of PUCCHs and PUSCHs of different priorities in step 2.2, if HP PUCCH resource carrying HARQ-ACK and all negative SR(s) overlaps with LP PUSCH, HP HARQ-ACK is multiplexed in LP PUSCH and all negative HP SR(s) are dropped.
[109-e-R17-IIoT-URLLC-03] – Jia (OPPO)
Email discussion on intra-UE multiplexing/prioritization B by May 18
- Issue#1 HP PUCCH with HARQ-ACK and SR collides LP HARQ-ACK
- Issue#2 Multiplexing for SPS HARQ-ACK
- Issue#3 Interlace number adjustment for PUCCH
- Issue#4 Power control enhancement for PUCCH
- Issue#5 Clarification on PUCCH resource determination in spec
- Issue#6 Insufficient resources of HP PUSCH multiplexed with LP HARQ-ACK
- Issue#7 Multiplexing of CG-UCI on PUSCH of a different priority
- Issue#8 Bitwidth of Beta-offset indicator
- Issue#10 Spec clarification reflecting the agreement on DG-CG PUSCH prioritization
- 1st check point on May 12 and final check point on May 18
R1-2205190 Summary#1 of email thread [109-e-R17-IIoT-URLLC-03] Moderator (OPPO)
From May 12th GTW session
Agreement
For the scenarios where multiplexing low-priority HARQ-ACK onto high-priority PUSCH, down-select from the options:
· Option 2: LP HARQ-ACKs are mapped to the rest REs of the PUSCH based on the rate matching equation, if HP HARQ-ACK and/or HP CSI have been mapped in prior on the PUSCH.
R1-2205306 Summary#2 of email thread [109-e-R17-IIoT-URLLC-03] Moderator (OPPO)
Decision: As per email decision posted on May 19th,
Agreement
· The text proposal in Section 6 of R1-2205306 is endorsed for the editor’s CR on TS28.213 (Clause 9.2.5.3).
Agreement
When cg-UCI-Multiplexing is enabled, for PUSCH with CG UCI multiplexing with HARQ-ACK, if any,
· CG-UCI has the same priority as the PUSCH.
· Treat the CG-UCI of a certain priority as if a HARQ-ACK of the same priority.
· Joint encode CG-UCI with HARQ-ACK of the same priority if it exists.
· Then reuse the existing multiplexing rules.
Conclusion
For multiplexing HP HARQ-ACKs and LP HARQ-ACKs, it is confirmed that current specification is interpreted as the following.
· The PRI in the lastly received DCI (if exist), which schedules a HP HARQ-ACK involved in the multiplexing, is used to select the PUCCH resource to transmit the multiplexed UCI payload.
· Note: No spec update is needed
For any other maintenance issues on enhanced Industrial Internet of Things (IoT) and URLLC
R1-2205103 Preparatory phase FL summary for URLLC/IIoT operation on unlicensed band- [109-e-Prep-AI8.3 R17 URLLC/IIoT] Moderator (Ericsson)
R1-2205133 Feature lead summary on PDC for preparation phase Moderator (Huawei)
R1-2203190 The remaining issue on propagation delay compensation enhancements ZTE
R1-2203275 Maintenance of Rel-17 URLLC/IIoT Propagation Delay Compensation Nokia, Nokia Shanghai Bell
R1-2203399 Remaining Issues for Propagation Delay Compensation Enhancements Ericsson
R1-2204004 Remaining issues of URLLC PDC OPPO
R1-2204618 Remaining issues on Unlicensed band URLLC operation LG Electronics
R1-2204893 Other remaining issues for URLLC and IIoT Huawei, HiSilicon
[109-e-R17-IIoT-URLLC-04] – Sorour (Ericsson)
Email discussion on unlicensed band URLLC/IIoT (issues captured in R1-2105103) by May 18
- Issue#1: COT association for PUSCH scheduled via RAR (R1-2204618)
- Issue#2: Correction of maximum value of RRC parameter offsetUE (R1-2204893) for IIoT/URLLC RRC parameters Email discussion during RAN1#109-e if it is not resolved by RAN2 by start of RAN1#109-e.
- Issue#3: Editorial TPs for 37.213 (R1-2204893) conditioned that are quickly supported without controversy. Otherwise drop Issue#3 for discussion.
- 1st check point on May 12 and final check point on May 18
R1-2205263 Summary#1: [109-e-R17-IIoT-URLLC-04] Maintenance of URLLC/IIoT operation on unlicensed band Moderator (Ericsson)
Decision: As per email decision posted on May 11th,
Agreement
Include in the IIoT/URLLC RRC parameters LS to RAN2, the following clarification:
· The proper maximum values for the parameter offsetUE in SemiStaticChannelAccessConfigUE are 139/279/559 for 15/30/60kHz SCS rather than 279/559/1119, and the proper value range is thus 559 rather than 1119.
Agreement
The text proposal in Section 3 (Proposal 2) of R1-2205263 is endorsed for the editor’s CRs on TS 37.213 V 17.1.0 (Clause 4.3 and Clause 4.3.1).
Final summary in R1-2205264.
[109-e-R17-IIoT-URLLC-05] – Chengyan (Huawei)
Email discussion on propagation delay compensation enhancements by May 18
- Issue 1: Text proposal for QCL source of PDC PRS
- Issue 2: Text proposal for measurement report
- 1st check point on May 12 and final check point on May 18
R1-2205134 Summary#1 of email discussion on propagation delay compensation enhancements Moderator (Huawei)
Decision: As per email decision posted on May 13th,
Agreement
· The text proposal in section 2.1.2 of R1-2205134 for TS 38.214 is endorsed for the editor’s CR.
Final summary in R1-2205135.
[110-R17-IIoT_URLLC] Email to be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc – Klaus (Nokia)
R1-2205790 Discussion on the timing for semi-static PUCCH pattern Huawei, HiSilicon
R1-2205791 Correction on PUCCH repetition with semi-static PUCCH cell switching Huawei, HiSilicon
R1-2205949 Draft CR for semi-static PUCCH cell switch and PUCCH repetitions ZTE
R1-2206147 [Draft CR] RRC parameter corrections for Rel-17 enhanced IIoT and URLLC for NR in 38.212 Nokia, Nokia Shanghai Bell
R1-2206148 [Draft CR] RRC parameter corrections for Rel-17 enhanced IIoT and URLLC for NR in 38.213 Nokia, Nokia Shanghai Bell
R1-2206149 [Draft CR] RRC parameter corrections for Rel-17 enhanced IIoT and URLLC for NR in 38.214 Nokia, Nokia Shanghai Bell
R1-2206150 [Draft CR] Corrections to DCI field size definitions for DCI formats 1_1 and 1_2 for the secondary PUCCH group for Rel-17 URLLC / IIoT HARQ-ACK feedback enhancements Nokia, Nokia Shanghai Bell
R1-2206151 [Draft CR] Correction to Rel-17 URLLC / IIoT HARQ-ACK codebook retransmission triggering indication Nokia, Nokia Shanghai Bell
R1-2206152 [Draft CR] Correction on semi-static PUCCH cell switching and PUCCH repetitions PDCCH Nokia, Nokia Shanghai Bell
R1-2206153 Discussion document for 38.213 Draft CR: Correction on semi-static PUCCH cell switching and SCell activation / dormancy to active Nokia, Nokia Shanghai Bell
R1-2206154 [Draft CR] Correction on semi-static PUCCH cell switching and SCell activation / dormancy to active Nokia, Nokia Shanghai Bell
R1-2206228 [Draft CR] RRC parameter corrections for Rel-17 enhanced IIoT and URLLC for NR in 37.213 Nokia, Nokia Shanghai Bell
R1-2206474 Clarification on semi-static PUCCH cell switching for PUCCH repetitions NEC
R1-2206739 Correction on PUCCH repetition for semi-static PUCCH cell switching vivo
R1-2206795 Maintenance on HARQ-ACK feedback enhancements Samsung
R1-2206939 Draft CR on time point to apply PUCCH cell switching pattern CATT
R1-2206941 Draft CR for simultaneous configuration of semi-static PUCCH cell switching and PUCCH repetition CATT
R1-2206942 Draft CR on SPS HARQ-ACK deferral CATT
R1-2207032 Remaining issues on HARQ-ACK feedback enhancements LG Electronics
R1-2207188 Correction for joint operation of semi-static PUCCH cell switch and PUCCH repetitions Qualcomm Incorporated
R1-2207189 Correction for HARQ-ACK codebook generation for PUCCH cell switching and UL BWP switching Qualcomm Incorporated
R1-2207190 Discussion on timeline for PUCCH cell switch with Scell activation, deactivation, and dormancy Qualcomm Incorporated
R1-2207501 Correction on HARQ-ACK retransmission indicator ASUSTeK
R1-2207627 Correction on semi-static PUCCH cell switching and PUCCH repetitions Ericsson
R1-2207658 Correction for HP PUCCH with HARQ-ACK and SR colliding LP HARQ-ACK Huawei, HiSilicon
R1-2207659 Correction on enhanced Type 3 HARQ-ACK codebook in 38.212 Huawei, HiSilicon
R1-2207660 Correction on HARQ-ACK enhancement related RRC parameters in 38.213 Huawei, HiSilicon
R1-2207661 Correction on PUCCH carrier switching related RRC parameters in 38.213 Huawei, HiSilicon
R1-2207662 Discussion on the missed RRC parameters from higher layer parameter list Huawei, HiSilicon
R1-2207779 Moderator summary #1 on RRC parameter corrections for NR Rel-17 URLLC/IIoT Moderator (Nokia)
From Tuesday session
For alignment CRs
· For 38.212:
o The identified RRC parameter corrections by Nokia /NSB in R1-2206147 are referred to the 38.212 editor alignment CR.
· For 38.213:
o The identified RRC parameter corrections by Nokia / NSB in R1-2206148 are referred to the 38.213 editor alignment CR.
o The identified RRC parameter corrections by Huawei / HiSilicon in R1-2207661 are referred to the 38.213 editor alignment CR.
o The identified RRC parameter corrections by ETRI in Sec. 2.2. of R1-2206948 are referred to the 38.213 editor alignment CR.
· For 38.214:
o The identified RRC parameter corrections by Nokia / NSB in R1-2206149 are referred to the 38.214 editor alignment CR.
· For 37.213:
o The identified RRC parameter corrections by Nokia / NSB in R1-2206228 are referred to the 37.213 editor alignment CR.
R1-2207777 Moderator summary #1 on Maintenance of HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
From Tuesday session
For alignment CRs
· The identified required changes by Nokia / NSB in R1-2206150 are to be reflected in the 38.212 editor alignment CR.
· The identified required changes by Nokia / NSB and ASUSTeK in R1-2206151 are to be reflected in the 38.213 editor alignment CR.
· The identified required changes by CATT in R1-2206942 are to be reflected in the 38.213 editor alignment CR.
· The identified required changes by Huawei / HiSilicon in R1-2207660 are to be included in the 38.213 editor alignment CR.
R1-2207778 Moderator summary #2 on Maintenance of HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
R1-2208029 Correction for HARQ-ACK codebook generation for PUCCH cell switching and UL BWP switching Moderator (Nokia), Qualcomm
Decision: The draft CR is endorsed. Final CR (38.213, Rel-17, CR#0347, Cat F) is agreed in R1-2208101.
Final summary in R1-2208102.
R1-2206948 Remaining issues on Enhanced IIoT and URLLC ETRI
R1-2206949 Draft CR on Enhanced IIoT and URLLC ETRI
R1-2207310 Maintenance on Enhanced Industrial Internet of Things (IoT) and URLLC Apple
R1-2207804 FL summary of Rel-17 URLLC/IIoT intra-UE MUX A Moderator (CATT)
R1-2205792 Remaining issue for HP SPS HARQ-ACK colliding with LP HARQ-ACK Huawei, HiSilicon
R1-2205793 Remaining issue for HP PUCCH with HARQ-ACK and SR colliding LP HARQ-ACK Huawei, HiSilicon
R1-2205950 Discussion on multiplexing PUCCH carrying HP SR and HP HARQ with PUCCH carrying LP HARQ-ACK ZTE
R1-2206229 Accompanying discussions on draft CRs to 38.213 on Rel-17 URLLC / IIoT Intra-UE Multiplexing/Prioritization Nokia, Nokia Shanghai Bell
R1-2206230 [Draft CR] Collision resolution involving LP PUCCH with HARQ-ACK and CSI/SR Nokia, Nokia Shanghai Bell
R1-2206231 [Draft CR] Handling of PUCCH with high-priority HARQ-ACK and HP SR overlapping with a PUCCH with low-priority HARQ-ACK Nokia, Nokia Shanghai Bell
R1-2206232 [Draft CR] Handling of high-priority PUCCH with SPS PDSCH HARQ-ACK only overlapping with a low-priority PUCCH with HARQ-ACK Nokia, Nokia Shanghai Bell
R1-2206366 HP PUCCH format 0/1 with SR and HARQ-ACK overlapping with LP HARQ-ACK CATT
R1-2206425 Draft CR on UE procedure for overlapping CG PUSCH and DG PUSCH ZTE
R1-2206544 Correction on HP DG PUSCH and LP CG PUSCH collision resolution Intel Corporation
R1-2206545 Remaining issue for Intra-UE Uplink Channel Multiplexing and Prioritization Intel Corporation
R1-2206740 Draft CR on HP PUCCH with HARQ-ACK and SR colliding with LP HARQ-ACK vivo
R1-2206741 Draft CR on multiplexing for HP SPS HARQ-ACK vivo
R1-2206796 Maintenance on Intra-UE Multiplexing/Prioritization Samsung
R1-2207033 Remaining issues on Intra-UE multiplexing enhancements LG Electronics
R1-2207191 Discussion on remaining issues on intra-UE multiplexing and prioritization Qualcomm Incorporated
R1-2207192 Correction for intra-UE multiplexing and prioritization Qualcomm Incorporated
R1-2207310 Maintenance on Enhanced Industrial Internet of Things (IoT) and URLLC Apple
R1-2207490 Remaining Issues of Intra-UE Multiplexing/Prioritization for IIoT/URLLC Ericsson
R1-2207491 Collision of HP PUCCH PF0/1 with {HARQ-ACK, SR} and LP HARQ-ACK Ericsson
R1-2207492 Corrections on DG-CG PUSCH prioritization Ericsson
R1-2207596 Remaining issues on intra-UE multiplexing/prioritization for URLLC/IIoT WILUS Inc.
R1-2207657 Correction for HP SPS HARQ-ACK colliding with LP HARQ-ACK Huawei, HiSilicon
R1-2207852 Summary#1 on intra-UE multiplexing/prioritization B Moderator (OPPO)
From Tuesday session
Conclusion
RAN1 concluded that the following is already captured in current specification.
· When a HP positive SR in PUCCH format 0/1 overlaps with LP HARQ-ACK and SR in PUCCH format 0/1, LP HARQ-ACK and SR are dropped.
Agreement
When a PUCCH carrying explicit/implicit HP SR and HP HARQ-ACK, for HP SR with F1 and HP HARQ-ACK with F0/F1, and HP SR with F0 and HP HARQ-ACK with F0 overlaps with a PUCCH carrying LP HARQ-ACK, where the original PUCCH carrying the HP HARQ-ACK before Step 1 overlaps with K HP SRs , K>=1
Agreement
To resolve overlapping between a HP PUCCH carrying positive SR and HP HARQ-ACK with PUCCH format 0/1 and a LP PUCCH carrying HARQ-ACK and CSI/SR, the LP HARQ-ACK and LP CSI/SR are dropped.
· No specification change is needed.
Agreement
For resolving collision of two overlapping PUCCHs with different priorities in R17, if a HP PUCCH with SPS PDSCH HARQ-ACK only overlaps with a LP PUCCH with HARQ-ACK and sps-PUCCH-AN-List is not provided in the second PUCCH-config, the LP PUCCH is dropped.
R1-2208004 Summary#2 on intra-UE multiplexing/prioritization B Moderator (OPPO)
Agreement
· Adopt the following text proposal for Section 6.1 of TS 38.214.
****************************************
6.1 UE procedure for transmitting the physical uplink shared channel
<Unchanged parts are omitted>
A
UE is not expected to be scheduled by a PDCCH ending in symbol 
to transmit
a PUSCH on a given serving cell overlapping in time with a transmission
occasion, where the UE is allowed to transmit a PUSCH with configured grant
according to [10, TS38.321], starting in a symbol 
on the same
serving cell if the end of symbol is not at
least 
symbols
before the beginning of symbol , if the UE is not provided prioritizationBetweenLP-DG-PUSCHandHP-CG-PUSCH or prioritizationBetweenHP-DG-PUSCHandLP-CG-PUSCH,
or the UE is provided prioritizationBetweenLP-DG-PUSCHandHP-CG-PUSCH or prioritizationBetweenHP-DG-PUSCHandLP-CG-PUSCH
and the two PUSCHs have the same priority index as described in Clause 9 of [6,
TS 38.213]. The value in symbols
is determined according to the UE processing capability defined in Clause 6.4,
and 
and the
symbol duration are based on the minimum of the subcarrier spacing
corresponding to the PUSCH with configured grant and the subcarrier spacing of
the PDCCH scheduling the PUSCH.
<Unchanged parts are omitted>
R1-2208094 Draft CR on UE procedure for overlapping CG PUSCH and DG PUSCH Moderator (OPPO), ZTE, Ericsson
Decision: The draft CR is endorsed. Final CR (38.214, Rel-17, CR#0322, Cat F) is agreed in R1-2208225.
Agreement
· Adopt the following text proposal for Section 9 of TS 38.213.
****************************************
*** Unchanged text is omitted ***
9 UE procedure for reporting control information
If a UE would transmit the following channels, including repetitions if any, that would overlap in time
· - a first PUCCH of larger priority index with SR and a second PUCCH or PUSCH of smaller priority index, or
· - a configured grant PUSCH of larger priority index and a PUCCH of smaller priority index, or
· - a first PUCCH of larger priority index with HARQ-ACK information only in response to PDSCH(s) reception without corresponding PDCCH(s) and a second PUCCH of smaller priority index with HARQ-ACK information only in response to PDSCH(s) reception without corresponding PDCCH(s), or a second PUCCH of smaller priority index with SR and/or CSI, or a configured grant PUSCH with smaller priority index, or a PUSCH of smaller priority index with SP-CSI report(s) without a corresponding PDCCH, or
· - a PUSCH of larger priority index with SP-CSI reports(s) without a corresponding PDCCH and a PUCCH of smaller priority index with SR, or CSI, or HARQ-ACK information only in response to PDSCH(s) reception without corresponding PDCCH(s), or
· - a configured grant PUSCH of larger priority index and a configured grant PUSCH of smaller priority index on a same serving cell
· - a PUSCH of smaller priority index scheduled by a DCI format and a configured grant PUSCH of larger priority index on a same serving cell if the UE is provided prioritizationBetweenLP-DG-PUSCHandHP-CG-PUSCH
· - a PUSCH of larger priority index scheduled by a DCI format and a configured grant PUSCH of smaller priority index on a same serving cell if the UE is provided prioritizationBetweenHP-DG-PUSCHandLP-CG-PUSCH
the UE is expected to cancel a repetition of the PUCCH/PUSCH transmissions of smaller priority index before the first symbol overlapping with the PUCCH/PUSCH transmission of larger priority index if the repetition of the PUCCH/PUSCH transmissions of smaller priority index overlaps in time with the PUCCH/PUSCH transmissions of larger priority index. In case of a PUSCH of larger priority index scheduled by a DCI format in a PDCCH reception and a configured grant PUSCH of smaller priority index on a same serving cell and the UE is provided prioritizationBetweenHP-DG-PUSCHandLP-CG-PUSCH
·
- the UE expects that the
transmission of the PUSCH of larger priority index would not start before 
after a last
symbol of the corresponding PDCCH reception
·
- 
is the PUSCH
preparation time for a corresponding UE processing capability assuming 
[6, TS
38.214], based on 
and as
subsequently defined in this clause, and 
and 
are
determined by a reported UE capability
*** Unchanged text is omitted ***
Final CR(38.213, Rel-17, CR#0355, Cat F) is agreed in:
R1-2208226 CR on HP DG PUSCH and LP CG PUSCH collision resolution Moderator (OPPO), Intel Corp
[110bis-e-R17-IIoT-URLLC-01] – Klaus (Nokia)
Email discussion to determine maintenance issues to be handled in RAN1#110bis-e by October 12
- Additional email discussions will be set up once the maintenance issues for RAN1#110bis-e are determined
R1-2208473 Correction for HP SPS HARQ-ACK colliding with LP HARQ-ACK Huawei, HiSilicon
R1-2208866 Draft CR on intra-UE multiplexing OPPO
R1-2209033 Remaining issue for Intra-UE Uplink Channel Multiplexing and Prioritization Intel Corporation
R1-2209034 Correction on CSI on LP PUSCH with CG-UCI Intel Corporation
R1-2209467 Draft CR for multiplexing for SPS HARQ-ACK ZTE
R1-2209560 Maintenance on Enhanced Industrial Internet of Things (IoT) and URLLC Apple
R1-2209697 Draft CR for PUCCH power control for multiplexing HARQ-ACK of different priorities in a PUCCH Samsung
R1-2209698 Draft CR for overlapping of a HP PUCCH with SPS PDSCH HARQ-ACK and a LP PUCCH with HARQ-ACK Samsung
R1-2210027 Correction on UCI multiplexing with different priority indexes ITRI
R1-2210028 Correction on coding scheme for HARQ-ACK with small block length ITRI
R1-2210148 Accompanying discussions on draft CRs to 38.213 on Rel-17 URLLC / IIoT Intra-UE Multiplexing/Prioritization Nokia, Nokia Shanghai Bell
R1-2210149 [Draft CR] Handling of PUCCH with high-priority HARQ-ACK and HP SR overlapping with a PUCCH with low-priority HARQ-ACK Nokia, Nokia Shanghai Bell
R1-2210150 [Draft CR] Handling of high-priority PUCCH with SPS PDSCH HARQ-ACK only overlapping with a low-priority PUCCH with HARQ-ACK Nokia, Nokia Shanghai Bell
R1-2210464 Summary#1 on intra-UE multiplexing/prioritization B Moderator (OPPO)
[110bis-e-R17-IIoT-URLLC-02] – Jia (OPPO)
Email discussion on remaining maintenance issues on intra-UE mux B by October 17
- Issue#2: CR reflecting the agreement on multiplexing for SPS HARQ-ACK
- Issue#3: Power control for PUCCH
- Issue#5: Whether LP P-CSI can multiplex with HP HARQ-ACK on a LP CG PUSCH
- Issue#6: Priority of CG-UCI
- For alignment CR: Issue#4: Correct clause number in TS 38.212 for small block coding for HARQ-ACK
R1-2210465 Summary#1 for email discussion [110bis-e-R17-IIoT-URLLC-02] Moderator (OPPO)
R1-2210466 Draft CR on multiplexing for SPS HARQ-ACK Moderator (OPPO), Samsung, LGE, Huawei, HiSilicon, OPPO, ZTE, Nokia, Nokia Shanghai Bell
Decision: As per email decision posted on Oct 17th, the draft CR (for Issue#2) is endorsed. Final CR (TS 38.213, Rel-17, CR#0381, Cat F) is agreed in R1-2210632.
For the editors
· The text proposal in R1-2210028 for TS 38.212 is provided as an editorial correction for alignment CR.
Decision: As per email decision posted on Oct 18th,
Agreement
The following text proposals are endorsed.
· Issue#3:
o R1-2210639 Draft CR on power control for PUCCH Moderator (OPPO), Apple, Samsung, Ericsson
o Final CR (TS 38.213, Rel-17, CR#0385, Cat F) is agreed in R1-2210676
MCC post meeting: To delete "Draft" in CR title; correct typo in Tdoc#
· Issue#6:
o R1-2210640 Draft CR on priority of CG-UCI Moderator (OPPO), ITRI, Huawei, HiSilicon, LG Electronics, Ericsson
o Final CR (TS 38.212, Rel-17, CR#0128, Cat F) is agreed in R1-2210677
MCC post meeting: To delete "Draft" in CR title
Decision: As per email decision posted on Oct 19th,
Agreement
The following TP for CSI on LP PUSCH with CG-UCI is agreed.
“- drops Part 2 CSI reports of smaller priority index if the UE would multiplex the HARQ-ACK information of smaller and larger priority indexes in a PUSCH where the UE multiplexes Part 1 CSI reports and Part 2 CSI reports of smaller priority index”
R1-2210467 Draft CR on CSI on LP PUSCH with CG-UCI Moderator (OPPO), Intel Corp, Qualcomm, Ericsson, Samsung
Decision: As per email decision posted on Oct 19th, the draft CR (for Issue#5) is endorsed. Final CR (TS 38.213, Rel-17, CR#0407, Cat F) is agreed in R1-2210773.
R1-2208465 Discussion on PUCCH repetition with semi-static PUCCH cell switching Huawei, HiSilicon
R1-2208599 Correction on RRC parameters for enhanced Type-3 codebook in TS38.212 vivo
R1-2208600 Correction on RRC parameters for enhanced Type-3 codebook in TS38.213 vivo
R1-2208864 Draft CR on e-type 3 HARQ codebook OPPO
R1-2208865 Draft CR on HARQ-ACK retransmission OPPO
R1-2208938 Discussion on simultaneous configuration of semi-static PUCCH cell switch and PUCCH repetitions CATT
R1-2209448 Remaining issues on HARQ-ACK feedback enhancements LG Electronics
R1-2209466 Discussion on remaining issue of PUCCH cell switching ZTE
R1-2209699 Draft CR for SPS HARQ-ACK deferral Samsung
R1-2209700 Discussion on the timeline of determining SPS HARQ-ACK deferral Samsung
R1-2209945 Correction for joint operation of semi-static PUCCH cell switch and PUCCH repetitions Qualcomm Incorporated
R1-2209946 Discussion on timeline for PUCCH cell switch with Scell activation, deactivation, and dormancy Qualcomm Incorporated
R1-2210142 Correction on semi-static PUCCH cell switching and PUCCH repetitions Ericsson
R1-2210145 [Draft CR] Correction on PUCCH cell switching Nokia, Nokia Shanghai Bell
R1-2210146 On semi-static PUCCH cell switching and PUCCH repetition operation Nokia, Nokia Shanghai Bell
R1-2210147 [Draft CR] Correction on semi-static PUCCH cell switching and PUCCH repetitions Nokia, Nokia Shanghai Bell
[110bis-e-R17-IIoT-URLLC-03] – Klaus (Nokia)
Email discussion on remaining maintenance issues on HARQ-ACK feedback enhancements by October 18
- Issue#1: PUCCH repetition with semi-static PUCCH cell switching
- For alignment CR: Issue#2 – RRC parameter corrections
- Issue#3: MCS field of the first TB used for enh. Type 3 CB indication and HARQ-ACK re-tx slot offset indication
- Issue#4: Clarification on overlapping PUCCH for SPS HARQ-ACK deferral
- Issue#5: k1 / PDSCH-to-HARQ for semi-static PUCCH cell switching
R1-2210720 Moderator summary: Maintenance of HARQ-ACK feedback enhancements for NR Rel-17 URLLC/IIoT Moderator (Nokia)
Decision: As per email decision posted on Oct 13th,
For the editors:
The following editorial changes are provided to improve the clarity of the RAN1 specifications. Please include them in the alignment CRs.
· The identified RRC parameter corrections in R1-2208599 for 38.212
· The identified RRC parameter corrections in R1-2208600 for 38.213
R1-2210530 Correction on enhanced Type 3 HARQ-ACK codebook and HARQ-ACK re-transmission triggering Moderator (Nokia), OPPO
Decision: As per email decision posted on Oct 14th, the text proposal in R1-2210530 is endorsed for 38.213. Final CR (TS 38.213, Rel-17, CR#0379, Cat F) is agreed in R1-2210626.
Decision: As per email decision posted on Oct 20th,
Agreement
· Adopt the following TP on semi-static PUCCH cell switching and PUCCH repetition to 38.213:
|
9.A PUCCH cell switching This
clause is applicable when a UE is provided a PUCCH-sSCell by pucch-sSCell
and the PUCCH-sSCell
is activated and does not have a dormant UL/DL active BWP. This
clause is not applicable for slots of the UL reference SCS configuration where
the UE would transmit a PUCCH with A UE can be provided a periodic cell switching pattern for PUCCH transmissions by pucch-sSCellPattern. Each bit of the pattern corresponds to a slot for a reference SCS configuration provided by tdd-UL-DL-ConfigurationCommon for the PCell with a value of '0' or a value of '1' indicating, respectively, the PCell or the PUCCH-sSCell as the cell for PUCCH transmissions during the slot of the reference SCS configuration. The UE does not transmit a PUCCH in a slot on a cell if the pattern indicates a different cell for PUCCH transmission during the slot. A slot on the active UL BWP of the PUCCH-sSCell does not overlap with more than one slot on the active UL BWP of the PCell. If a slot for the active UL BWP of the PCell overlaps with more than one slot on the active BWP of the PUCCH-sSCell and the UE would transmit a PUCCH on the PUCCH-sSCell, the UE considers the first of the overlapping slots for the PUCCH transmission on the PUCCH-sSCell. < Unchanged parts are omitted > |
Final CR (38.213, Rel-17, CR#0408, Cat F) is agreed in:
R1-2210774 Correction of PUCCH repetition for semi-static PUCCH cell switching Moderator (Nokia), Nokia Shanghai Bell, ZTE, Ericsson, New H3C
R1-2212833 Session notes for 8.3 (Maintenance on Enhanced Industrial Internet of Things (IoT) and URLLC) Ad-hoc Chair (CMCC)
Endorsed and contents incorporated below.
[111-R17-IIoT_URLLC] – Klaus (Nokia)
To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2210971 Correction on triggering of enhanced Type-3 codebook in TS38.213 vivo
R1-2211493 Draft CR on joint operation of Rel-17 intra-UE multiplexing and SPS HARQ deferral OPPO
R1-2211278 Editorial correction on UE initiated semi-static channel access parameters in TS 38.212 ZTE, Sanechips
R1-2211279 Editorial correction on UE initiated semi-static channel access parameters in TS 38.214 ZTE, Sanechips
R1-2212455 Correction on RRC parameters in 38.213 Huawei, HiSilicon
R1-2212456 Correction on RRC parameters in 38.214 Huawei, HiSilicon
R1-2212310 Corrections on RRC parameter name alignment for IIOT in TS38.213 Sharp
R1-2212085 Correction on 4-bit subband CQI feedback Qualcomm Incorporated
R1-2210861 Correction on PUCCH cell switching in 38.213 Huawei, HiSilicon
R1-2212794 Moderator summary #1 on Maintenance NR Rel-17 URLLC/IIoT: HARQ-ACK feedback enhancements & RRC parameter alignment Moderator (Nokia)
R1-2212795 Correction on triggering of enhanced Type-3 codebook Moderator (Nokia), vivo
Decision: The draft CR in R1-2212795 is endorsed for 38.213 in principle. Final CR (38.213, Rel-17, CR#0419, Cat F) is agreed in R1-2212880.
MCC post-meeting: Change WI code to NR_IIOT_URLLC_enh-Core
Agreement
The following editorial changes are provided to improve the clarity of the RAN1 specifications. Please include them in the alignment CRs.
· The identified RRC parameter corrections in R1-2211278 for 38.212
· The identified RRC parameter corrections in R1-2211279 for 38.214
· The missing table reference in R1-2212085 for 38.214
· The identified RRC parameter corrections in R1-2212456 for 38.214
· The identified RRC parameter corrections in R1-2212455 for 38.213
R1-2211260 Correction on sub-slot based HARQ-ACK transmission for PUCCH cell switching CATT
R1-2212796 Correction on PUCCH cell switching Moderator (Nokia), CATT, Huawei, HiSilicon, Qualcomm
Decision: The draft CR in R1-2212796 is endorsed for 38.213 in principle. Final CR (38.213, Rel-17, CR#0420, Cat F) is agreed in R1-2212881.
R1-2212810 Correction on HARQ-ACK reporting on PUSCH for Rel-17 Intra-UE multiplexing Moderator (Nokia), Huawei, HiSilicon
Decision: The draft CR in R1-2212810 is endorsed for 38.213 in principle. Final CR (38.213, Rel-17, CR#0421, Cat F) is agreed in R1-2212882.
R1-2212797 [Draft] LS on Rel-17 URLLC/IIoT RRC parameter update Moderator (Nokia)
Draft LS is withdrawn.
Final summary in R1-2212883.
R1-2211519 Correction on sub-slot description for UCI transmission CATT
R1-2211636 Draft CR on PUCCH transmission after multiplexing UCI with different priorities ZTE
R1-2212746 Summary#1 on intra-UE multiplexing/prioritization B Moderator (OPPO)
R1-2212747 Draft CR on PUCCH transmission after multiplexing UCI with different priorities Moderator (OPPO), ZTE, Huawei, HiSilicon
No consensus on the proposed correction.
R1-2212084 Correction on UE procedure for reporting HARQ-ACK with PUCCH cell switch Qualcomm Incorporated
R1-2212479 Correction on UCI reporting at PUSCH in 38.213 Huawei, HiSilicon
R1-2302053 Session notes for 8.3 (Maintenance on Enhanced Industrial Internet of Things (IoT) and URLLC) Ad-hoc Chair (CMCC)
[112-R17-IIoT_URLLC] – Klaus (Nokia)
To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2302010 Moderator summary #1 on Maintenance NR Rel-17 URLLC/IIoT Moderator (Nokia)
From Wednesday session
R1-2301725 Correction on semi-static channel occupancy Nokia, Nokia Shanghai Bell
R1-2301746 Correction on the reference of intra-UE multiplexing related clauses in 38.212 Huawei, HiSilicon
R1-2302011 Corrections on intra-UE multiplexing and semi-static channel occupancy Moderator (Nokia), Huawei, HiSilicon, Nokia, Nokia Shanghai Bell
Agreement
· The draft CR to 38.212 in R1-2302011 is endorsed in principle. Final CR is agreed in R1-2302083 (TS38.212, Rel-17, CR# 0136, Cat F).
MCC post meeting: Delete WI code "NR_L1enh_URLLC-Core" and replace by "NR_IIOT_URLLC_enh-Core" before submission to plenary
R1-2301235 Correction on timeline requirements when configured with uci-MuxWithDiffPrio Samsung
R1-2302013 Correction on timeline requirements when configured with uci-MuxWithDiffPrio Moderator (Nokia), Samsung
Agreement
· The draft CR to 38.214 in R1-2302013 is endorsed in principle. Final CR is agreed in R1-2302085 (TS38.214, Rel-17, CR# 0394, Cat F).
R1-2300072 Correction on semi-static PUCCH carrier switching Huawei, HiSilicon
R1-2300338 Draft CR on PUCCH transmission after multiplexing UCI with different priorities ZTE
R1-2301233 Correction on interaction between intra-UE prioritization and UL transmission collision with DL symbols Samsung
R1-2300364 Clarification on PUCCH transmission after multiplexing UCI with different priorities (TP to 38.213) Nokia, Nokia Shanghai Bell
R1-2301234 Correction on PUCCH power control for multiplexing HARQ-ACK of different priorities in a PUCCH Samsung
R1-2301751 Correction on power control of inter priority UCI multiplexing Huawei, HiSilicon
R1-2302012 Miscellaneous corrections on Rel-17 URLLC / IIoT in 38.213 Moderator (Nokia), Samsung, Huawei, HiSilicon, Nokia, Nokia Shanghai Bell
Agreement
· The draft CR to 38.213 in R1-2302012 is endorsed in principle. Final CR (TS38.213, Rel-17, CR#0442, Cat F) is agreed in:
R1-2302084 Miscellaneous corrections on Rel-17 URLLC / IIoT in 38.213 Moderator (Nokia), Samsung, Huawei, HiSilicon, Nokia, Nokia Shanghai Bell, ZTE
R1-2300646 Correction on the definition of last DCI in Rel-17 CATT
R1-2300647 Correction on HARQ-ACK multiplexing on PUSCH with different priority CATT
Final summary in R1-2302082.
